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About This Book 



This publication contains the information necessary to code job control language (JCL), job 
entry subsystem 2 (JES2) control statements, and job entry subsystem 3 (JES3) control, 
statements. It is intended for use by programmers who code JCL, JES2, and JES3 control 
statements and who understand the concepts of job management and data management. 

The book is divided into several chapters: 

• The Introduction and the first seven chapters are a guide to using JCL, JES2, and JES3 
control statements, written primarily for the inexperienced user of JCL. It contains 
background information necessary to understand why to code certain parameters, sample 
situations illustrating when to code these parameters, and descriptions of how to code 
combinations of parameters to perform particular functions. Examples of jobs involving a 
variety of parameters are included. The descriptions of JCL services are grouped into 
seven chapters: Requesting Resources and Identifying Data, Routing a Job Through the 
System (JES2 only). Obtaining Output (JES2 only), Routing a Job Through the System 
(JES3 only), Obtaining Output (JES3 only). Special Data Sets, and Cataloged and 
In-stream Procedures. 

• The next four chapters describe the parameters, their syntax, and rules for coding. The 
descriptions include the format of each JCL, JES2, and JES3 control statement and the 
format of the parameters associated with each statement. Parameters for the control 
statements are presented in alphabetical order giving a brief definition and a reference to 
the appropriate publication or section for a detailed explanation of the facility or service 
to be used. The definition and reference are followed by a default, rules for coding, and 
at least one example of how to code the control statement or parameter. The descriptions 
are grouped into four chapters: Programming Notes, JCL statements, JES2 statements, and 
JES3 statements. 

• The last three sections contain reference tables, the glossary, and the index for quick 
retrieval of information. 

JCL Statements no Longer Supported or Supported Differently 

A few parameters introduced in OS are no longer supported in VS2 Release 3.7. Main storage 
heirarchy support and the roUout/roUin features are not available in vs. The system will check 
the HIERARCHY and ROLL parameters only for correct syntax. 

The SEP and AFF parameters and the UNIT=SEP subparameter have no meaning in VS2. If 
they are coded, they are ignored. If JES2 is used, PRTY is ignored. 

JCL DD parameters supported differently are SPLIT and SUBALLOC. Their values are 
internally converted to SPACE requests. If JES3 is used, the UNIT parameter on a DD statement 
which names a cataloged data set cannot specify a device type that conflicts with the cataloged 
device type (for example, a 3330 and a 2314). The REGION parameter on the JOB and EXEC 
statement has the same nleaning as in OS/MVT and VS2 Release 1 unless modified by the 
installation. In virtual storage requests, REGION can be coded to act as an upper limit for 
variable-length GETMAIN requests. 
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JCL Statements New to VS2 Release 3.7 

Refer to Figure 1 for parameters that are new to VS2 Release 3.7. 



Statement 


Parameter 


Description 


JESS 

FORMAT 

PR 


PRTY 
TRIPLE 


Specifies priority of data set entering output queue. 
Subparameter of CONTROL; specifies triple spacing. 


JESS 
MAIN 


ACHOLD 

ACMAIN 
EXPDTCHK 

JOURNAL 
USER 


Specifies disposition of SYSOUT data sets routed to a TSO 
user. 

Identifies the job with a processor. 

Allows expiration date checking to be done on scratch SL 
output tape volumes. 

Indicates whether job is to have a journal. 

Identifies job with a TSO user. 



Figure 1. New Parameters for VS2 Release 3.7 



F^ure lA. New Statements and Parameters for JES2 Release 4.0 (VS2.03.803) 
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Statement 


Parameter 


Description 


JOB 


Accounting 
Information 

PRTY 

JCLHOLD 


JES2 parameters added to maintain compatibility. 

Specifies a job's queue selection priority for JES2 only. 
Subparameter of TYPRUN for JES2 only. 


DD 


DEST 


New subparameters added for JES2. 


JES2 
JOBPARM 


RESTART 


Specifies whether a job is to be queued for re-execution. 


JES2 
OUTPUT 


COPYG 

BURST 

CHARS 

FLASH 

FUSHC 

MODIFY 

MODTRC 


New parameters to support the S800 Printing Subsystem. 


JES2 
SIGNOFF 




Specifies that the user wishes to terminate a remote job 
stream processing session. 


JES2 
SIGNON 




Specifies that the user wishes to begin a remote job stream 
processing session. 
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Statement 


Parameter 


Description 


JOB 


GROUP 

PASSWORD 

USER 


Allows a RACF-defined user to specify a group name. 
Verifies the identity of a RACF-defined user. 
Identifies a RACF-defined user. 


DD 


RETAIN 


Subparameter of VOLUME; retains tape volume at end of job 
step. 



Figure IB. New Parameters in Scheduler Improvements (VS2.03.804) 



Statement 


Parameter 


Description 


DD 


BURST 
CHARS 
FLASH 
group value 

MODIFY 
OPTCD = J 


Specifies the Burster-Trimmer-Stacker of the S800. 

Specifies character arrangement tables for the 3800. 

Identifies forms overlay for the S800. 

Subparameter of COPIES; describes grouping of printed copies 
when the 3800 is used. 

Specifies a copy modification module for use with the 3800. 

Subparameter of DCB; specifies that the first byte of each 
output data line is a table reference character used to select a 
character arrangement table. 


JESS 
FORMAT 


PR 


CHARS, STACKER, FLASH and MODIFY are additional 
subparameters. 



F^e IC. New Parameters for the IBM 3800 Printii^ Subsystem (VS2.03.810) 

The book assumes the reader has a basic knowledge of computer operating systems and 
some familiarity with job control language. Background information on VS2 is included in the 
OS/VS2 Planning Guide for Release 2, GC28-0667. 



Prerequisite Publications 

Introduction to Virtual Storage in System/370, GR20-4260. 
Introduction to OS/VS2 Release 2, GC28-0661. 

Publications to which the text refers: 

Data Processing Glossary, GC20-1699. 

OS/VS2 Planning Guide for Release 2, GC28-0667. 

OS/VS Checkpoint/Restart, GC26-3784. 

OS/VS2 System Programming Library: Data Management, GC26-3830. 

OS/VS2 System Programming Library: Debugging Handbook, GBOF-8211. 

OS/VS2 System Programmmg Library: Job Management, GC28-0627. 

OS/VS2 Supervisor Services and Macro Instructions, GC28-0683. 

OS/VS Tape Labels, GC26-3795. 

OS/VS Data Management Macro Instructions, GC26-3793. 

Operator's Library: OS/VS2 Reference (JES2), GC38-0210. 

Operator's Library: OS/VS2 Reference (JES3), GC38-0226. 

OS/VS2 System Programming Library: JES3, GC28-0608. 

OS/VS2 MVS System Programming Ubrary: JES2, GC23-0001. 
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OS/VS2 MVS System Programming Library: JES2, GC23-0002. (VS2.03.803) M 

OS/VS2 MVS System Programming Library: VTAM, GC28-0688. (VS2.03.803) ■ 

OS/VS2 System Programming Library: Initialization and Tuning Guide, GC28-0681. 

OS/VS Data Management Services Guide, GC26-3783. 

OS/VS2 Access Method Services, GC26-3 841. 

OS/VS Virtual Storage Access Method (VSAM) Programmer's Guide, GC26-3838. 

OS/VS Utilities, GC35-0005. 
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OS/VS2 System Programming Library: System Management FacUities (SMF), GC28-0706. 

OS and OS/VS Programming Support for the IBM 3505 Card Reader and IBM 3525 Card Punch, 

GC21-5097. 

OS/VS2 Using OS Catalog Management with the Master Catalog: CVOL Processor, GC35-0010. 

OS/VS2 TCAM Programmer's Guide, GC30-2041. 

OS/VS BTAM, GC27-6980. 

Graphic Programming Services for 2250, GC27-6971. 

Graphic Programming Services for 2260, GC27-6972. 

IBM 3340 Fixed Head Feature Users Guide, GA26-1632. 

IBM 2821 Control Unit, GA24-3312. 

IBM 3800 Printing Subsystem Programmer's Guide, GC26-3846. (VS2.03.810) 

Forms Design Reference Guide for the IBM 3800 Printing Subsystem, GA26-1633. (VS2.03.810) 

OS/VS Mass Storage System (MSS) Services for Space Management, GC35-0012. 

OS/VS2 System Programming Library: System Generation Reference, GC26-3792. 

OS/VS2 System Programming Ubrary: Service Aids, GC28-0674. 

OS/VS2 System Programming Library: Supervisor, GC28-0628. 

OS/VS2 IBM 3540 Programmer's Reference, GC24-5111. 

OS/VS2 TSO Command Language Reference, GC28-0646. 
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About This Book 



This publication contains the information necessary to code job control language (JCL), job 
entry subsystem 2 (JES2) control statements, and job entry subsystem 3 (JES3) control 
statements. It is intended for use by programmers who code JCL, JES2, and JES3 control 
statements and who understand the concepts of job management and data management. 

The book is divided into several chapters: 

• The Introduction and the first seven chapters are a guide to using JCL, JES2, and JES3 
control statements, written primarily for the inexperienced user of JCL. It contains 
background information necessary to understand why to code certain parameters, sample 
situations illustrating when to code these parameters, and descriptions of how to code 
combinations of parameters lo perform particular functions. Examples of jobs involving a 
variety of parameters are included. The descriptions of JCL services are grouped into 
seven chapters: Requesting Resources and Identifying Data, Routing a Job Through the 
System (JES2 only). Obtaining Output (JES2 only). Routing a Job Through the System 
(JES3 only). Obtaining Output (JES3 only). Special Data Sets, and Cataloged and 
In-stream Procedures. 

• The next four chapters describe the parameters, their syntax, and rules for coding. The 
descriptions include the format of each JCL, JES2, and JES3 control statement and the 
format of the parameters associated with each statement. Parameters for the control 
statements are presented in alphabetical order giving a brief definition and a reference to 
the appropriate publication or section for a detailed explanation of the facility or service 
to be used. The definition and reference are followed by a default, rules for coding, and 
at least one example of how to code the control statement or parameter. The descriptions 
are grouped into four chapters: Programming Notes, JCL statements, JES2 statements, and 
JES3 statements. 

• The last three sections contain reference tables, the glossary, and the index for quick 
retrieval of information. 

JCL Statements no Longer Supported or Supported Differently 

A few parameters introduced in OS are no longer supported in VS2 Release 3.7. Main storage 
heirarchy support and the rollout/roUin features are not available in vs. The system will check 
the HIERARCHY and ROLL parameters only for correct syntax. 

The SEP and AFF parameters and the UNIT=SEP subparameter have no meaning in VS2. If 
they are coded, they are ignored. If JES2 is used, PRTY is ignored. 

JCL DD parameters supported differently are SPLIT and SUBALLOC. Their values are 
internally converted to SPACE requests. If JES3 is used, the UNIT parameter on a DD statement 
which names a cataloged data set cannot specify a device type that conflicts with the cataloged 
device type (for example, a 3330 and a 2314). The REGION parameter on the JOB and EXEC 
statement has the same meaning as in OS/MVT and VS2 Release 1 unless modified by the 
installation. In virtual storage requests, REGION can be coded to act as an upper limit for 
variable-length GETMAIN requests. 
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JCL Statements New to VS2 Release 3.7 

Refer to Figure 1 for parameters that are new to VS2 Release 3.7. 



Statement 


Parameter 


Description 


JES3 

FORMAT 

PR 


PRTY 
TRIPLE 


Specifies priority of data set entering output queue. 
Subparameter of CONTROL; specifies triple spacing. 


JES3 
MAIN 


ACHOLD 

ACMAIN 
EXPDTCHK 

JOURNAL 
USER 


Specifies disposition of SYSOUT data sets routed to a TSO 
user. 

Identifies the job with a processor. 

Allows expiration date checking to be done on scratch SL 
output tape volumes. 

Indicates whether job is to have a journal. 

Identifies job with a TSO user. 



Figure 1. New Parameters for VS2 Release 3.7 



Statement 


Parameter 


Description 


JOB 


Accounting 
Information 

PRTY 

JCLHOLD 


JES2 parameters added to maintain compatibility. 

Specifies a job's queue selection priority for JES2 only. 
Subparameter of TYPRUN for JES2 only. 


DD 


DEST 


New subparameters added for JES2. 


JES2 
JOBPARM 


RESTART 


Specifies whether a job is to be queued for re-execution. 


JES2 
OUTPUT 


COPYG 

BURST 

CHARS 

FLASH 

FLASHC 

MODIFY 

MODTRC 


New parameters to support the 3800 Printing Subsystem. 


JES2 
SIGNOFF 




Specifies that the user wishes to terminate a remote job 
stream processing session. 


JES2 
SIGNON 




Specifies that the user wishes to begin a remote job stream 
processing session. 



Figure I A. New Statements and Parameters for JES2 Release 4.0 (VS2.03.803) 
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Statement 


Parameter 


Description 


JOB 


GROUP 

PASSWORD 

USER 


Allows a RACF-defined user to specify a group name. 
Verifies the identity of a RACF-defined user. 
Identifies a RACF-defined user. 


DD 


RETAIN 


Subparameter of VOLUME; retains tape volume at end of job 
step. 



Figure IB. New Parameters in Scheduler Improvements (VS2.03.804) 



Statement 


Parameter 


Description 


DD 


BURST 
CHARS 
FLASH 
group value 

MODIFY 
OPTCD = J 


Specifies the Burster-Trimmer-Stacker of the 3800. 

Specifies character arrangement tables for the 3800. 

Identifies forms overlay for the 3800. 

Subparameter of COPIES; describes grouping of printed copies 
when the 3800 is used. 

Specifies a copy modification module for use with the 3800. 

Subparameter of DCS; specifies that the first byte of each 
output data line is a table reference character used to select a 
character arrangement table. 


JES3 
FORMAT 


PR 


CHARS, STACKER, FLASH and MODIFY are additional 
subparameters. 



Figure IC. New Parameters for the IBM 3800 Printing Subsystem (VS2.03.810) 

The book assumes the reader has a basic knowledge of computer operating systems and 
some familiarity with job control language. Background information on VS2 is included in the 
OS/VS2 Planning Guide for Release 2, GC28-0667. 

Prerequisite Publications 

Introduction to Virtual Storage in System/370, GR20-4260. 
Introduction to OS/VS2 Release 2, GC28-0661. 

Publications to which the text refers: 

Data Processing Glossary, GC20-1699. 

OS/VS2 Planning Guide for Release 2, GC28-0667. 

OS/VS Checkpoint/Restart, GC26-3784. 

OS/VS2 System Programming Library: Data Management, GC26-3830. 

OS/VS2 System Programming Library: Debugging Handbook, GBOF-8211. 

OS/VS2 System Programming Library: Job Management, GC28-0627. 

OS/VS2 Supervisor Services and Macro Instructions, GC28-0683. 

OS/VS Tape Labels, GC26-3795. 

OS/VS Data Management Macro Instructions, GC26-3793. 

Operator's Library: OS/VS2 Reference (JES2), GC38-0210. 

Operator's Library: OS/VS2 Reference (JES3), GC38-0226. 

OS/VS2 System Programming Library: JES3, GC28-0608. 

OS/VS2 MVS System Programming Library: JES2, GC23-0001. 
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OS/VS2 MVS System Programming Library: JES2, GC23-0002. (VS2.03.803) 

OS/VS2 MVS System Programming Library: VTAM, GC28-0688. (VS2.03.803) 

OS/VS2 System Programming Library: Initialization and Tuning Guide, GC28-0681 

OS/VS Data Management Services Guide, GC26-3783. 

OS/VS2 Access Method Services, GC26-3841. 

OS/VS Virtual Storage Access Method (VSAM) Programmer's Guide, GC26-3838. 

OS/VS Utilities, GC35-0005. 
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I OS/VS2 System Programming Library: System Management Facilities (SMF), GC28-0706. 

OS and OS/VS Programming Support for the IBM 3505 Card Reader and IBM 3525 Card Punch, 
GC21-5097. 

OS/VS2 Using OS Catalog Management with the Master Catalog: CVOL Processor, GC35-0010. 

OS/VS2 TCAM Programmer's Guide, GC30-2041. 

OS/VS BTAM, GC27-6980. 

Graphic Programming Services for 2250, GC27-6971. 

Graphic Programming Services for 2260, GC27-6972. 

IBM 3340 Fixed Head Feature Users Guide, GA26-1632. 

IBM 2821 Control Unit, GA24-3312. 

IBM 3800 Printing Subsystem Programmer's Guide, GC26-3846. (VS2.03.810) 

Forms Design Reference Guide for the IBM 3800 Printing Subsystem, GA26-1633. (VS2.03.810) 

OS/VS Mass Storage System (MSS) Services for Space Management, GC35-0012. 

OS/VS2 System Programming Library: System Generation Reference, GC26-3792. 

OS/VS2 System Programming Library: Service Aids, GC28-0674. 

OS/VS2 System Programming Library: Supervisor, GC28-0628. 

OS/VS2 IBM 3540 Programmer's Reference, GC24-5111. 

OS/VS2 TSO Command Language Reference, GC28-0646. 
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Summary of Amendments 
for GC28-0692-2 
OS/VS2 Release 3.7 



Changes have been made throughout this publication to 
reflect a Service Update - 0S/VS2 Release 3.7. In addition 
pertinent technical and editorial changes have been made. 

PROCESS and ENDPROCESS Statements (JES3) 

These statements, for nonstandard job processing, are now 
described in this manual. 



DD Statement under JES3 

Job terminates if duplicate ddnames exist in a step; reserved 
ddnames are included. 



DATASET Statement (JES3) 

Additional rules for coding. 

FORMAT Statement (JES3) 

AC DEST parameter rewritten; rules for coding DDNAME 
and DEST are clarified. 

LABEL Parameter 

Syntax and rules for coding are clarified. 

TIME Parameter 

Relationship of TIME on the JOB and the EXEC statement 
is clarified. 

UNIT Parameter 

P subparameter and rules for coding AFF are clarified. 

VOLUME Parameter 

PRIVATE subparameter is rewritten; RETAIN 
subparameter is now supported to ensure that a volume 



remains mounted until the end of the job; rules for coding 
are clarified. 

AMP Parameter 

The AMORG and BUFSP subparameters are clarified. 

DCB Parameter 

Additional information for completing a data control block; 
descriptions of several subparameters are expanded. 

PARM Parameter 

Continuation of expressions on another statement is 
clarified. 

Direct Access Devices 

Tables updated to reflect the addition of the 3344 and 3350 
storage devices. 

Command Statement 

All JCL command statements are ignored by JES3. 

DEST Parameter 

REMOTEn is not a valid subparameter for JES2. 

Region Size Requirements 

For ADDRSPC=VIRT, two internal values are established 
to limit all GETMAINs. 

Creating an ISAM Data Set 

If a nonspecific volume request is made, and space is not 
available on the volume selected, the job fails. 
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Summary of Amendments 
for GC28-0692-1 
as Updated by GN28-2600 
OS/VS2 Release 3 



i 



JES3 for Planning Purposes Only 

The restriction that JES3 information is for planning 
purposes only is no longer in effect. 



COPIES Parameter on the DD Statement 

The maximum number of copies is limited to 254 for JESS. 

Command Statement (JES3) 

N is not a valid parameter of the Command statement. 

FORMAT AC Statement (JES3) 

Clarification of the USER, HOLD, and MAIN parameters. 

FORMAT PR Statement (JES3) 

TRIPLE is an additional option for the CONTROL 
parameter; PRTY is a new parameter that specifies the 



priority at which the data set is to enter the output queue; 
syntax of COPIES parameter is changed; the DEST 
parameter overrides the MAIN ORG parameter. 

FORMAT PU Statement (JES3) 

Syntax of COPIES parameter is changed; the DEST 
parameter overrides the MAIN ORG parameter. 

MAIN Statement (JES3) 

EXPDTCHK, JOURNAL, USER, ACMAIN, and 
ACHOLD are additional parameters on the MAIN 
statement. 



NET Statement (JES3) 

Clarification of the RELEASE, NETREL, DEVPOOL, and 
DEVRELSE parameters. 
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Summary of Amendments 
for GC28-0692-1 
OS/VS2 Release 3 



JES3 (for planning purposes only) 

Includes all JCL related information and parameters for 
JES3. 



JES2 JOBPARM Statement 

SYSAFF'is a new parameter that indicates the systems 
eligible to process a given job (for JES2). 



AMP and DCB Parameters 

DCB rewritten; AMP and DCB relocated in alphabetical 
order in the DD statements. 



DEST Parameter 

The DEST parameter value is clarified for JES2 and 
non-JES2 users. 



Allocation 

Additional information on device status affecting eligibility 
for allocation; additions to specific volume and unit 
requests; additions to unit affinity; additions to UNIT and 
VOLUME parameters. 

Space Requests 

Additional information in requesting space and in the 
SPACE parameter. 

Restart 

Checkpoint data sets must have UNIT and VOLUME 
specified even if cataloged. 

Label 

Additions to label type subparameter and creating a model 
data set label for generation data groups. 

Job Initiation Priority 

JES3 supports the PRTY parameter on the JOB statement. 

Testily JCL without Execution 

PGM=JCLTEST, in addition to TYPRUN=SCAN, tests 
JCL syntax. 



Reference Tables 

The tables are updated to reflect the Release 3 changes. 

MisceHaneous 

The SPACE, UNIT, and VOLUME parameters are some of 
the parameters clarified in this release. 

Unit Affinity 

Data sets requesting unit affinity can be overridden in 
certain circumstances. 

Mass Storage System (MSS) (for plannii^ purposes 
only) 

Mass storage volumes are virtual direct access devices 
defined in groups of volumes by the MSVGP parameter. 

Associated Data Sets 

These are data sets on a 3540 diskette and are identified by 
the DSID parameter. 

TYPRUN=COPY 

The input deck is converted directly to a SYSOUT data set 
and scheduled for output processing, bypassing job 
initiation. 



Dynamic Allocation 

Additional rules for coding the DYNAM parameter. 

Comment Statement 

Clarification of continuing the comments statement. 

Device Sharability 

Describes what device types are sharable between jobs, 
including the 3340 fixed head feature drive. 



VIO Data Sets 

When allocating VIO data sets by average block length, the 
secondary request is determined by the average block length 
specified in the SPACE parameter. 

TIME=0 

On the JOB statement: no CPU time limit is assigned. On 
the EXEC statement: the remaining time from the previous 
step is used. 

DD * and DD DATA 

New keywords are allowed on these two statements. 
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Introduction 



You can write programs in any one of a number of languages. The operating system will 
translate the language into machine language so that the instructions can be executed and the 
work performed. There is also a language, called job control language (JCL), that directs the 
operating system in the handling of appUcation programs. When submitting programs to the 
operating system, you can provide JCL statements to define the work to be done, the methods 
to be used, and the resources needed. In addition, you can obtain special input and output 
processing by including JES2 and JESS control statements for the job entry subsystems. A 
collection of related problem programs is submitted to the operating system as a job. A job is 
made up of one or more job steps, each of which is a unit of work associated with the overall 
processing program. 



The JCL Statements 



Job control language consists of nine statements. The name and purpose of each statement is 
summarized in Figure 2. 

Every job requires the use of the JOB statement (to identify the job), EXEC statements (to 
identify each job step), and DD statements (to identify data sets used by the job). The null 
statement is optional. Placing it within the job causes JCL statements other than the JOB 
statement behind the null statement to be ignored. JES2 ignores the null statement. The 
delimiter statement can be used to indicate the end of data in the input stream. PROC and 
PEND statements are used to define a set of JCL statements to be used as an in-stream 
procedure. The command statement allows operator conmiands to be submitted through the 
input stream; this statement is used primarily by the operator. The comment statement can be 
used to make the programs readily understandable by other programmers and by yourself. 



Name of Statement 


Purpose 


// JOB (job) 
// EXEC (execute) 

// DD (data definition) 

/* (or two characters 
designated by tiie user 
\o indicate delimiter) 

// (null) 

// PROC (procedure) 

// PEND (procedure end) 
//* (comment) 
// (command) 


marks the beginning of a job; assigns a name to the job. 

marks the beginning of a job step; identifies the programs to be 

executed or the cataloged or in-stream procedure to be called; assigns a 

name to the step. 

identifies a data set and describes its attributes. 

indicates the end of data placed in the input stream. 

marks the end of a job. 

for cataloged procedures, assigns default values to parameters defined in 

the procedure; for in-stream procedures, marks the beginning of the 

procedure. 

marks the end of in-stream procedure. 

contains comments. 

enters system operator commands through the input stream. 



F^ure 2. Job Control Statements 

In addition to identifying data sets, job steps, and the job, you can code parameters on JCL 
statements to request resources and services from the operating system. The operating system, 
together with your job entry subsystem, is responsible for managing all the resources of the 
computing system. It automatically performs many services in processing jobs; however, you 
can influence the processing of a job by including JCL parameters. For example, JES2 selects a 
job for execution, but you can influence when the job is selected or delay its selection by 
coding parameters on the JOB statement (or on the MAIN statement for JES3 processed jobs). 
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You can also ask for a specific volume on which to write a data set. The following paragraphs 
describe some of the functions that are available on the major JCL statements: 

JOB statement: By using the parameters allowed on the JOB statement, you can provide 
accounting information for the installation's accounting routines, define execution 
characteristics, specify conditions for early termination of the job, request a specific class for 
job scheduler messages, hold a job for later execution, and limit the maximum amount of time 
the job can use the central processing unit (CPU). 

EXEC statement: Parameters on the EXEC statement can define the program or cataloged 
procedure that the system is to execute. They can also be used to provide job step accounting 
information, to give conditions for bypassing or executing a job step, to assign a limit on the 
CPU time used by a job step, and to pass information to a processing program such as the 
linkage editor. 

DD statement: Parameters on the DD statement provide the system with such information as 
the name of the data set, the name of the volume on which it resides, the ij^Q of I/O device 
that holds the data set, the format of the records in the data set, whether a data set is old or 
new, the size of newly created data sets, and the access method that will be used to create or 
refer to the data. 



The JES2 Statements 



You can control the input, output, and processing of a program by coding JES2 control 
statements and placing them in the input stream. There are seven JES2 statements that can be 
used with JCL to direct the execution of the program. Figure 3 shows the name and purpose of 
each statement. 



Nfune of Statement 


Purpose 


/♦$command 
/♦JOBPARM 
/♦MESSAGE 
/•OUTPUT 

/♦PRIORITY 

/♦ROUTE 

/♦SETUP 


enters JES2 operator commands through the input stream. 

indicates job related parameters that can be specified at input time. 

sends messages to the operator via the operator console. 

specifies characteristics and options of a specific SYSOUT data set or 

SYSOUT data sets. 

assigns a job selection priority. 

specifies the default output destination. 

indicates volumes needed for executing your job. 


groups of 



Figure 3. JES2 Control Statements 

Use JES2 control statements to request more efficient use of resources. Three of these 
statements contain specific functions that are discussed below. 

JOBPARM statement: Parameters on the JOBPARM statement specify the estimated number of 
cards to be produced as output from a job, the number of copies of printed output desired, the 
default print or punch forms, the number of output lines on each page, the estimated total 
number of output lines from the job, your room number, any system affinity that may be 
required, the estimated job execution time, the printing of the JES2 job log, and the name of 
the cataloged procedure library to be used to convert the JCL for the job. 

OUTPUT statement: Parameters on the OUTPUT statement specify the number of copies of 
each data set that is desired, the destination device of the output, any special forms required, 
the indexing print position offset and forms control buffer image (FCB) (3211 only), and the 
use of the universal character set (UCS). 
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ROUTE statement: Parameters on the ROUTE statement route the printed or punched output 
to any local device, remote terminal, or remote device. 



The JES3 Statements 



You can also control the input, output, and processing of a program by coding JES3 control 
statements and placing them in the input stream. There are eight JES3 statements that can be 
used with JCL to direct the execution of a program. Figure 4 shows the name and purpose of 
each statement. 



Nanie of Statement 


Purpose 


//**command 


enters JESS operator commands, except *DUMP and ♦RETURN, through the input 




stream. 


//*DATASET 


permits additional input data sets from the input stream. 


//*ENDDATASET 


terminates the creation of an input data set. 


//*ENDPROCESS 


terminates a series of PROCESS statements. 


//'FORMAT 


specifies special destination and format related instructions for a specific SYSOUT or 




JES3-managed print and punch data set. 


//*MAIN 


defines selected processing parameters for the current job. 


//*NET 


identifies relationships between predecessor and successor jobs in a dependent job 




6ontrol net. 


//♦OPERATOR 


transmits messages to the operator. 


//**PAUSE 


halts the input reader. 


//♦PROCESS 


identifies a nonstandard job. 



F^e 4. JES3 Control Statements 

Several of the JES3 statements contain keyword parameters that define options available to 
help improve the processing of the job. Two of these statements are briefly defined here. 

FORMAT statement: Parameters on the FORMAT statement differ according to the type of 
request you are making. For print and punch data sets, keyword parameters specify such 
options as output destination, number of output copies, and types of output forms. For JESS 
created data sets (AC) under MVT or VS2 Release 1, kejrword parameters specify options for 
TSO users or local users wishing to route data sets to TSO users on MVT or VS2/1 asp main 
processors. For network job processing data sets (njp), keyword parameters specify the JES3 
system name from which and to which the job will be transmitted. 

MAIN statement: Parameters on the MAIN statement specify such options as the main 
processor name or tjrpe of system to be used for the job, the type of control procgram to be 
used, the estimated number of cards or lines of output, the job class for the job, and the time 
that the job is due to be completed. Additional options allow TSO users or local users to route 
all eligible output of a job to TSO users on MVT or VS2/1 ASP main processors. 

Nonstandard job processai^. A job, in addition to being a collection of related problem 
programs identified by a JOB statement, is also a collection of JES3 processing segments, called 
job segments. A job that consists only of a collection of related problem programs to be 
processed by VS2 and that requires no special job segments is called a standard job. A 
nonstandard job requires one or more special job segments in place of or in addition to the 
standard job segments of interpreter service, main service, and output service. Specify a 
nonstandard job by following the JOB statement with a JES3 process statement for each job 
segment. 

Cataloged and In-Stream Procedures 

Often the same set of JCL statements are used repeatedly with little or no change (for 
example, to specify compilation, link-editing, and execution of programs). To save 
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programming time and to reduce the possibility of error, standard job step definitions can be 
prepared and placed (or cataloged) in a partitioned data set known as the procedure library. A 
set of JCL statements placed in the procedure library is called a cataloged procedure. A 
cataloged procedure consists of EXEC and DD statements. 

By simply using a JOB statement and an EXEC statement, you can retrieve a specific 
cataloged procedure. Specify the name of the procedure on the exec statement. 

The effect is the same as if the JCL statements of the cataloged procedure appeared in the 
input stream in the place of the exec statement that calls the procedure. If necessary, you can 
modify the cataloged procedure by a process known as overriding. 

Before putting a procedure into the procedure library, you may want to test it. This can be 
done by converting the procedure to an in-stream procedure. An in-stream procedure is a set 
of JCL statements that can be used repeatedly by referencing it in an EXEC statement. Another 
advantage of in-stream procedures is that they can give you the facility of a cataloged 
procedure without being placed in the procedure library. After testing the procedure, keep it in 
card form and simply insert it in the input stream whenever you want to use it. 



Processing Your Job 



To have a job processed, submit the JCL statements and any related input data to the 
operating system through an input/output (l/O) device chosen by the operator. The input unit 
can be a card reader, a magnetic tape, a terminal, or a direct access device. The sequence of 
JCL statements and input data for all the jobs being submitted through an input unit is called 
the input stream. 

A job control language (JCL) statement consists of one or more 80-byte records. Many jobs 
are submitted to the operating system for execution in the form of 80-column punched cards. 
The operating system is able to distinguish a job control statement from data included in the 
input stream. In columns 1 and 2 of all the statements except the delimiter statement, code //. 
For the delimiter statement, code /*. For a comment statement, code //* in the first three 
columns. 

A job can be simple or complicated; you can have a procedure in the input stream or call a 
cataloged procedure. Figure 5 shows some examples of what jobs can look Uke, Although only 
one example shows the use of the JES2 statements, these statements could have been placed 
with all of the jobs. (JES3 statements can also be used with any of the jobs and are placed 
after the JOB statement.) 
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c 



delimiter 



'7\ 



data 



(U DP 

n\ EXEC 
/^T JOB 



A Job With One Job Step 

The EXEC statement defines the program to be 
executed; the DD statements define the data to 
be used. There is also data in the input stream. 



c 



delimiter 



^ data 




(UYX DD * 






/// EXEC 




^ 


^11 JOB 




\ 




A Job With a Cataloged Procedure 

The EXEC statement is calling a cataloged 
procedure to process the data in the input 
stream. 



DDNAME=XY 



SYS1.PR0CLIB 



(l 



(h 



I 



(l 



(11 EXEC 



delimiter 



// PEND 



DD 



EXEC 



// PROC 



// JOB 



A Job With an In-stream Procedure 

The EXEC statement refers to an in-stream 
procedure which is shown using the PROC and 
PEND statements. 



DD 



/// EXEC 

^/'OUTPUT 



//•JOBPARM 

/il JOB 
_J 

I f /•PRIORITY 



Figure 5. A Job in the Input Stream 



A Job With JES2 Statements 

A simple job using JES2 control statements. The 
PRIORITY, command, and any comment 
statements would be the only control statements to 
be placed in front of the JOB statement. 
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Figure 6 shows a job that contains several job steps: a compilation, a link-edit, and a 
program. 




X { n DD 




^ { II EXEC 






^ // JOB 





Figure 6. A Job with Several Job Steps 

Figure 7 shows how several jobs run one after another through the input stream. Your job 
would be one job in a group of jobs that make up an input stream. 



c 




(JES2 only) 



/^ { It DD 




( II EXEC 






/ // JOB 





Figure 7. Job Boundaries in tiie Input Stream 
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Requesting Resources and Identifying Data 



To execute a program, define its requirements for resources and data. For example, if the job 
is to use only real storage, that is, it cannot be paged, you must indicate this on a JCL 
statement. You can also request certain units and volumes to be used and define the amount of 
space required by the job. If you request dynamic allocation, you are requesting resources 
during program execution as they are needed. 

Define temporary or nontemporary data sets or request the use of a nontemporary data set 
that is cataloged. Whether a data set is old or new, should be kept or deleted, are a few of the 
options you can define in establishing the disposition of data sets in the job. 

This section contains six topics: 

Requesting Storage for Execution of a Program 
Requesting Units and Volumes 
Requesting Space for Non-VSAM Data Sets 
Dynamically Allocating and Deallocating Data Sets 
Identifying Data Sets to the System 
Disposition Processing of Non-vSAM Data Sets 

Requesting Storage for Execution of a Program 

In OS/VS, storage available for a program consists of real storage and virtual storage: 

• Real storage is the storage of System/370 from which the central processing unit can 
directly obtain instructions and data and to which it can directly return results. 

• Virtual storage is addressable space that appears to the user as real storage, from which 
instructions and data are mapped into real storage locations. The user address space is 16 
milli on b5^es which consists of the commonly addressable system storage, the nucleus, and 
the private address space (which includes the user's region). 

When a program is selected, it is brought into virtual storage and divided into pages (a page 
is 4K in VS2). The supervisor is responsible for transferring pages of a program into real 
storage for execution. This paging is done automatically by the supervisor; to you, it appears as 
if the entire program exists in real storage. (The concept of paging is described in greater 
detail in the Introduction to Virtual Storage in System/370.) 

When to Request Real Storage 

For most programs, the supervisor transfers pages of a program to real storage as they are 
required for execution; not all pages of a program are necessarily iq real storage at one time 
and the pages that are in real storage at once do not necessarily occupy contiguous space. 
Certain programs, however, must have aU their pages in contiguous real storage while they are 
executing — they cannot be paged during execution. The programs include: 

• Programs that modify a channel program while it is active. 

• Programs that are highly time dependent. 

These programs must be placed into an area of virtual storage called the nonpageable 
dynamic area, whose virtual addresses are identical to real addresses; they are the only 
programs for which you should request real storage. If a job or job step must not be paged 
during execution, identify it by coding ADDRSPC=REAL on either the JOB or the EXEC 
statements. Request the amount of real storage needed with the REGION parameter. For more 
information concerning real and virtual storage, see the Introduction to 0S/VS2 Release 2. 
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specifying Storage Requirements with the REGION Parameter 

The meaning of the REGION parameter differs depending on whether the program can be 
paged during execution (if addrspc=virt is coded or implied) or cannot be paged during 
execution (if addrspc=real is coded). 

When ADDRSPC=VIRT is coded or implied, two values are established internally from either 
the REGION parameter or an installation-supplied default. When addrspc=real is coded, one 
value is established internally from either the REGION parameter or the installation-supplied 
default. These internal values are used to limit all GETMAlNs. (For further information, see 
OS/VS2 System Programming Library: Job Management, and the sections on the ADDRSPC and 
REGION parameters in this pubhcation.) 

The amount of space requested must include any additional requests the program makes 
during its execution (for example, a request made with the GETMAIN macro instruction). Also, 

I the amount of storage requested must include sufficient space for the task termination 
function. Task termination invokes certain system resource managers that can issue GETMAIN 

I macro instructions for space in the user's region. The region must have enough unallocated 

I storage during task termination to allow the task termination function to complete. 
When ADDRSPC=REAL is coded, the minimum region size must be 8K if the program to be 
executed is reenterable and resides in an authorized library, and 12K in all other cases. Note 
that this is the minimum region for successful execution, but not necessarily the minimum 
region size for successful job completion. It is suggested that programs to be run in an 
ADDRSPC=REAL environment perform as much clean-up as possible before terminating. 

Example of Requesting Storage 

The purpose of this job is to indicate how to request storage for a program when it is 
important that it not be paged. 

BROWN , CLASS=D , MSGLEVEL= 1 

PGM=REAL,REGION=20K,ADDRSPC=REAL 

DSN=DISK1 ,DISP=OLD 

PGM=VIRT , REGI0N=7 5K , ADDRSPC=VIRT 

DSN=DISK2 , DISP=OLD 

1. The JOB statement assigns jobs to class D and requests all JCL statements and messages 
to be printed. 

2. STEPl is to be executed in real storage. 

3. STEP2 is to be executed in virtual storage. 

Requesting Units and Volumes 

On the DD statement defining a data set, indicate the device and volume on which the data set 
can be found or will be written by specif3dng unit and volume information. Input/output 
devices are grouped according to class; a device class is a kind of device: direct access, 
magnetic tape, unit record, graphic, and communications equipment. A unit is a particular 
device: a 2314 direct access device, a 1403 printer, etc.; a volume is a section of auxiliary 
storage that is serviced by a single read/write mechanism — for example, a reel of magnetic 
tape, a drum, or a disk pack. 

Device status can affect the device eligibility for allocation. Figure 8 shows the various 
devices and the possible status each may have. 



f 



//OBJ 


JOB 


//STEPl 


EXEC 


//DD1 


DD 


//STEP2 


EXEC 


//DD2 


DD 



c 
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Status 


Device Type 


Direct Access 


Tape 


Unit Record 


Graphic 


Teleprocessing 


Online 


Eligible for allocation 


Offline 


Eligible for allocation when the operator brings device online 


Eligible for 
allocation 


Pending Unload 


Eligible for allocation when 
volume is specifically requested 


not applicable 


Pending Offline 


Eligible for allocation when 
the operator brings the device 
online and when the volume is 
specifically requested 


Eligible for allocation when the 
operator brings the device 
online 


not applicable 



Figure 8. How Device Status Affects El^jbility for AUocation 

Specifying Volume Information 

Data sets exist on direct access and magnetic tape volumes which must be mounted on devices 
before they can be used. To inform the system on which volume an existing data set can be 
found, make a specific volume request; to create a new data set, make a specific or nonspecific 
volume request. If you request multiple disk volimies to be mounted in JES3, they must all be 
either mountable or permanently resident; a mixture of both is not allowed. 

Specific Volume Requests 

A specific volume request informs the system of the volume serial number of the volume 
required. Make a specific volume request for an existing data set; make either a specific or 
nonspecific volume request when creating a data set. 

A specific request occurs when: 

• Specifying the serial numbers in the SER subparameter of the VOLUME parameter, that is, 
VOL=SER=(948762,94523 1). 

• Referring the system to an earUer specific volume request to copy the volume serial numbers 
by coding the name of a passed or cataloged data set or a previous DD statement in the REF 
subparameter of the VOLUME parameter. To refer the system to a passed or cataloged data 
set, code VOL=REF=dsname. To refer to a DD statement in the same step, code 
VOL=REF=*.ddname; in a preceding step, VOL=REF=*.stepname.ddname; or in a procedure 
step that is in a procedure called by a preceding step, 

VOL=REF=*.stepname.procstepname.ddname. (If you refer to a multi-device type VSAM data 
set, only the volume serial number of the first device type listed in the catalog will be used.) 

• Passing the data set from an earlier step or from the catalog. The system obtains the volume 
serial numbers from the passed data set information or from the catalog; you need not code 
the VOLUME parameter unless requesting a private volume, coding a volimie sequence 
number, or requesting additional volumes. If a cataloged data set is cataloged in, or is to be 
cataloged or uncataloged from, a private catalog other than JOBCAT and STEPCAT, then the 
system automatically allocates that private catalog to the job step. (The private catalog must 
be on a permanently resident volume in JES3). If this allocation is not successful, then the 
job fails. 

Nonspecific Volume Requests 

Nonspecific volume requests can be made only for new data sets. When making a nonspecific 
volume request, do not specify volume serial numbers. You need not code the VOLUME 
parameter unless you are requesting a private volume or a volume count. 
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There are four types of nonspecific volume requests that can be made: 

1. A private volume for a temporary data set. 

2. A private volume for a nontemporary data set. 

3. A nonprivate volume for a temporary data set. 

4. A nonprivate volume for a nontemporary data set. 

How the system satisfies these different types of requests is described below. Since the 
system satisfies the first two types of requests in the same way, these two requests are 
described together. 

• When making a nonspecific volume request for a private direct access or tape volume, the 
system always requests the operator to mount a volume. The operator should mount a 
volume whose space is unused. This allows you to havecontrol over all space on the 
volume. Once mounted, the volume is assigned the use attribute of private. 

• When making a nonspecific volume request for a nonprivate direct access volume that is to 
contain a temporary data set, the system assigns a public or storage volume that is already 
mounted, or requests the operator to mount a removable volume. If a mounted volume is 
selected, its use attribute is not affected. If a removable volume is mounted, it is assigned 
the use attribute of public. 

When making a nonspecific volume request for a nonprivate tape volume that is to 
contain a temporary data set, the system assigns a public volume that is akeady mounted, or 
it requests the operator to mount a tape volume. Once mounted, the volume is assigned the 
use attribute of public. 

• When making a nonspecific volume request for a nonprivate direct access volume that is to 
contain a nontemporary data set, the system assigns a storage volume if one is mounted. 
Otherwise, the request is treated as a nonspecific volume request for a private volume. 

When making a nonspecific volume request for a nonprivate tape volume that is to 
contain a nontemporary data set, the request is treated as a nonspecific volume request for 
a private volume. 



Using Private Volumes 

A private volume is one that can be used exclusively unless a specific request is made for that 
volume. Code PRIVATE as the first subparameter in the VOLUME parameter with both specific 
and nonspecific volume requests. When making a specific volume request for a direct access 
volume, code PRIVATE if you want a private volume; tape volumes for which you make a 
specific volume request are automatically made private, so you need not code the PRIVATE 
subparameter. 

A volume already made private caimot be allocated to satisfy other nonspecific volume 
requests. Therefore, if you request a private volume, you will be the only user using that 
volume, unless another job makes a specific volume request for that volume. 

If PRIVATE is coded or implied, the system automatically demounts the volume after its last 
use in the job step unless RETAIN is coded or the data set is passed. If you expect to use a 
data set in a subsequent step for which you requested a private volume, code RETAIN in the 
VOLUME parameter to ensure that the volume remains mounted until the end of the job. 

Sharing Volumes Between Data Sets 

To conserve space and use fewer volumes, request that data sets be assigned the same volume. 
Data sets on the same volume have volume affinity. 

You can request volume affinity either: 

I • Implicitly, through catalog references or by specifying the same volume serial numbers for 
the data sets in the SER subparameter of the VOLUME parameter. 
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• Explicitly, by using the REF subparameter of the VOLUME parameter to indicate that 

volumes identified in the catalog or on an earlier DD statement in the job are to be assigned 
to the data set being defined. 

Volume affinity influences the allocation of devices. The system can modify a request for a 
specific number of units if a data set has volume affinity with at least one other data set. For 
examples of volume affinity, see "Example of UNIT and VOLUME Affinities" at the end of this 
section. 



Multivolume Data Sets 



If you are creating or extending a data set that can require more than one volume, request the 
maximum number of volumes that can be required in the volume count subparameter of the 
VOLUME parameter. The maximum number of volumes you can request is 255. For some jobs, 
each volume requested must be mounted on a unit before it can be used. For these jobs, 
request as many units as volumes. When making a specific volume request for more volumes 
than units, the system automatically indicates that the volumes on the same unit cannot be 
shared. 

When reading or lengthening an existing multivolume data set, instruct the system to begin 
processing other than the first volume by coding the volume sequence number subparameter. 
Usually a volume sequence number is coded when you are defining an existing cataloged or 
passed data set. 

Specifying Unit Information 

Provide the system with the information it needs to assign a device to a data set in the UNIT 
parameter. To indicate what unit or type of unit you want, code one of the following: 

• Unit address. 

• Device type (generic name). 

• User-assigned group name (esoteric name). 

The unit address is a 3 -character address made up of the channel, control unit, and unit 
number. For example, UNIT=180 indicates channel 1, control unit 8, and unit number 0. 
Specifying a unit address, however, limits unit assignment: the system can assign only that 
specific unit, and, if the unit is being used, the job must be delayed or canceled. Unit 
addresses should only be specified when necessary since these specifications restrict the system. 

A device type corresponds to a particular set of features of input/output devices. When 
I coding a device type, you allow the system to assign any available device of that device type. 
For example, UNIT=2314 indicates that you want the system to assign an available 2314 disk 
storage facility. 

Each installation can also define user-assigned group names during system generation to 
signify a group of devices that may or may not all be of the same type. When coding a 
user-assigned group name, you allow the system to assign any available device included in the 
group. For example, if the group named DISK includes aU 2314 and 3330 disk storage facilities 
I and you code UNIT=DISK, the system assigns an available 2314 or 3330 device. If the group 
named 2314A includes particular 2314's and you code UNIT=2314A, it could refer to one of 
several groups of 2314 devices. 

If a group contains more than one device type or class (for example, SYSSQ can refer to all 
tape and direct access devices), you should not code the group name when defining an existing 
data set or requesting a specific volume. The volume on which the data set resides may require 
a device different from the one assigned to it. For example, if the data set resides on a tape 
volume, it must be assigned to a tape device. 
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The same is true if the data set resides on a 3348 Model 70F Data Module and the group 
name includes 3340 drives with and without the Fixed Head Feature. The 3348 Model 70F 
must be assigned to a 3340 with the feature. For more information on the Fixed Head 
Feature, see the IBM 3340 Fixed Head Feature Users Guide. 

Only direct access devices can be simultaneously allocated for two or more jobs. 
Teleprocessing equipment is not allowed to be allocated more than once in the same job step. 
If a unit record, teleprocessing equipment, or graphics device is designated as a console, it is 
not eligible for allocation by a job. 



I 



Requesting More than One Unit 

To increase operating efficiency, request multiple units for a multivolume data set or for a data 
set that may require additional volumes. When each required volume is mounted on a separate 
device, execution of the job step is not interrupted to allow the operator to demount and 
mount volumes. You should always request multiple units when the data set can be extended 
to a new volume if the data set resides on a permanently resident or reserved 
volume — permanently resident and reserved volumes cannot be demounted in order to mount a 
new volume. 

You request multiple units by: 

• Coding the unit count subparameter in the UNIT parameter. 

• Requesting parallel mounting. 

Request parallel mounting when making a specific or non-specific volume request. The 
system counts the number of volumes requested (by counting the volume serial numbers 
specified on the DD statement or counting the volume serial numbers in cataloged or passed 
data sets). This is compared with the volume count, if it has been specified, and the system 
assigns the larger of the specified number of devices. Code P in place of the unit count 
subparameter. 

Deferred Mounting of Volumes 

If the job step includes a data set that might not be used, depending on conditions determined 
in the job step, you can request (using the DEFER subparameter) that the system not mount 
the volume containing the data set until the data set is opened. This can save operator action 
I of mounting volumes on direct access devices. Note: No other job step can use such a volume 
untU the job step specifying DEFER ends. If DEFER is coded for a new data set which could be 
placed on a direct access device, then DEFER is ignored. 

When You Do Not Have to Code the UNIT Parameter 

The system can obtain unit information from sources other than the UNIT parameter. In these 
cases, you do not have to code the UNIT parameter: 

• When the data set is cataloged. For cataloged data sets, the system obtains unit and volume 
information from the catalog. However, if VOL=SER=serial number is coded on a DD 

I statement that defines a pre-existing data set, the system does not look in the catalog. In 
this case, you must code the UNIT parameter. 

• When the data set is passed from a previous job step. For passed data sets, the system 
obtains unit and volume information from passed data set information. However, if 

I yOL=SER=serial number is coded on a DD statement that defines a pre-existing data set, the 
system does not look in the passed data set information. In this case, you must code the 
UNIT parameter. 

• When the data set is to use the same volumes assigned to an earUer data set, that is, 
VOLUME=REF=reference is coded. In this case, the system obtains unit and volume 
information from an earlier DD statement that specified the volume serial number or from 
the catalog. 
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In all of the cases listed above, code the UNIT parameter when you want additional devices 
assigned or when you want to influence device allocation. If the coded UNIT parameter is a 
subset of the unit tjrpe referenced, then it will be used. Otherwise, it is ignored. However, 
when JES3 looks in the catalog, it cannot determine whether or not a given device type is a 
subset of another device type. Errors might result if you request one device to be mounted on 
a conflicting device type (for example, a 3330 mounted on a 2314). Do not code the UNIT 
parameter when defining a data set included in the input stream. If UNIT is coded on a DD * 
or DD DATA statement, the job abnormally terminates. 

Sharing a Unit Between Data Sets on Different Volumes 

To conserve the number of devices used in a job step, you can request that an existing data 
set be assigned to the same device or devices as assigned to a data set defined earlier in the 
job step. When two or more volumes are assigned the same device, the volumes are said to 
have unit affinity. Unit affinity implies deferred mounting for all except one of the volumes, 
since all volumes cannot be mounted on the same device at the same time. 

Request expUcit unit affinity by coding UNlT=AFF=ddname on a DD statement. The ddname 
is the name of an earUer DD statement in the same job step. The data set defined on the DD 
statement that requests unit affinity is assigned the same device or devices as the data set 
defined on the named DD statement. If the ddname refers to a DD statement that defines a 
dummy data set, the data set defined on the DD statement requesting unit affinity is assigned a 
dummy status. Unit affinity also exists on one DD statement when there are more volumes 
than units. This is imphed unit affinity. See examples of unit affinity. 

If all of the following conditions are present, the data set defined on the DD statement 
requesting unit affinity might be written over by the named data set: 

• The named DD statement requests a scratch tape. 

• The data set defined on the DD statement requesting unit affinity is opened prior to that on 
the named DD statement. 

• The tape is not unloaded prior to the OPEN of the data set defined on the named DD 
statement and tape label positioning is not specified using the LABEL parameter. 

Note: Unit affinity cannot be requested for a new data set if the referenced request is for a 
direct access device. 

Unit and Volume Affinities: Unit and volume affinity can occur in the same step and, within 
the step, on the same DD statement. There are three relationships possible between unit and 
volume affinity. 

1. All volume affinity requests are unrelated to any of the unit affinity requests. For 
example, 



//DD1 


DD 


VOL=SER=A 


//DD2 


DD 


UNIT=AFF=DD1 ,VOL=SER=B 


//DD3 


DD 


VOL=SER=(C,D) 


//DD4 


DD 


VOL=SER=C 



2. All volume affinity requests are contained in the unit affinity requests. For example, 

//DD 1 DD VOL=SER= ( A , D ) 

//DD2 DD UNIT=AFF=DD1 ,VOL=SER=(A,B) 

//DD3 DD VOL=SER=X 
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3. Some volume affinity requests are contained in the unit affinity requests, but not all. For 
example, 

//DD1 DD VOL=SER=A 

//DD2 DD UNIT=AFF=DD1 ,VOL=SER=B 

//DD3 DD VOL=SER=B 



i 



If both unit and volume affinity do exist in the same step, sometimes only one requested 
affinity can be honored at a time. Figure 9 indicates what will happen when you code unit and 
volume affinity for either tape or direct access devices. 
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unit affinity will use 
a different unit. 



Fi^e 9. Unit and Volume Affinity 

Note: U a requested volume is mounted on an eligible permanently resident or reserved unit, 
it must be allocated to that unit regardless of any relationships to other requests. This is done 
because no dismount of that particular volume can take place. 



c 
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Example of UNIT and VOLUME Affinities; The purpose of this job is to show several job 
steps that use either unit or volume affinity for their processing. 

(8526,831 ) , WOON , CLASS=J , PERFORM=50 

PGM^TESTAFF 

UNIT=2400,VOL=SER=1 11111 

UNIT=AFF=DD1 ,VOL=SER=222222 

PGM=TESTAFF 

UNIT=( 3330,2 ) , VOL=SER=( A,B ) 

UNIT=AFF=DD 1 1 , VOL=SER=( C , D ) 

PGM=TESTAFF 

UNIT=( 3330,2 ) , VOL=SER=( A, B ) 

UNIT=AFF=DD2 1 , VOL=SER=( C,D ) 

UNIT=3330,VOL-SER=B 

PGM=TESTAFF 

UNIT=( 3330,2 ) , VOL=SER=( E, F ) 

UNIT=AFF=DD3 1 , VOL=SER=( G , H ) 

PGM=TESTAFF 

UNIT=2400,VOL=SER=( 111111 ,222222 ) 

UNIT=AFF=DD41 ,VOL=SER=( 222222 ) 

PGM=TESTAFF 

UNIT-3330 , VOL=SER=( ABCDEF , GHIJKL ) 

UNIT=AFF=DD5 1 , VOL=SER=( ABCDEF ) 



//AFFIN 


JOB 


//STEP1 


EXEC 


//DD1 


DD 


//DD2 


DD 


//STEP2 


EXEC 


//DD11 


DD 


//DD12 


DD 


//STEP3 


EXEC 


//DD2 1 


DD 


//DD22 


DD 


//DD23 


DD 


//STEP4 


EXEC 


//DD31 


DD 


//DD32 


DD 


//STEPS 


EXEC 


//DD4 1 


DD 


//DD42 


DD 


//STEP6 


EXEC 


//DD51 


DD 


//DD52 


DD 



1. The JOB statement assigns jobs to class J in performance group 50. 

2. STEPl assigns one unit for both volumes. Volume 111111 will be mounted first, then 
222222 will be mounted when DD2 is opened. (This processing is true for both tape and 
direct access.) 

3. STEP2 allocates two units to DDll and volumes A and B are mounted. DD12 gets 
allocated to the same two units but volumes C and D will be mounted when DD12 is 
opened. 

4. STEP3 is a direct access example of volume affinity for volume B. The actual allocation 
of units will cause volumes A and C to share one unit and volumes B and D to have 
their own units. 

5. STEP4 is a direct access example. Assume that volume E is currently mounted and has 
been assigned the permanently resident or reserved attribute. In this case, since volume 
E cannot be dismounted, a separate unit will be allocated for it. Volume G will have its 
own unit and volumes F and H will share one unit. Therefore, three volumes will be 
allocated for these requests, instead of two, because of the permanently resident or 
reserved mount attributes. 

6. STEP5 is a tape example. Volume affinity is ignored between the DD statements because 
only one tape data set for each tape volume can be open at a time. 

7. STEP6 is a direct access example where unit affinity is ignored for the common volume. 
Volume ABCDEF of both DD statements will share the same unit while the remaining 
request (GHIJKL) will use a different unit. 

For more information, see OS/VS2 System Programming Library: Job Man^ement. 
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Example of Requesting Units and Volumes 

This job shows the unit and volume parameters. 



//TEST 


JOB 


//STEP1 


EXEC 


//DD11 


DD 


// 




//STEP2 


EXEC 


//DD2 1 


DD 


// 




//DD22 


DD 


// 




//DD23 


DD 


// 




//DD24 


DD 


// 




//DD25 


DD 


//DD26 


DD 



WIBORG, CLASSIC 

PGM^TESTSYSO 

DSN=A01DD1 ,UNIT=3330,DISP=( ,PASS ), 

SPACE=(TRK,1 ),VOL=SER=333001 

PGM=TESTSYSO 

DSN=SYSLIB , UNIT=23 1 4 , VOL=( PRIVATE , SER=1 23456 

DISP=OLD 

DSN=SYSABC,UNIT=AFF=DD21 , VOL=SER=777777 , 

DISP=( OLD, KEEP) 

DSN^SYSTAPE , UNIT=( 2400 , P , DEFER ) , DISP=OLD , 

VOL=SER=( 240001 ,240002,240003,240004,240005 ) 

DSN=SYSDISK,DISP=( SHR,KEEP ) ,UNIT=( , P ) , 

VOL=SER=( 333005,333008,333010 ) 

UNIT=2314,VOL=REF=*.DD21 , SPACE-( TRK, ( 5 , 2 ) ) 

UNIT=3330,VOL=REF=SYSDISK,SPACE=(TRK,( 10,5) ) 



1. The job is assigned to class C. 

2. DDll defines a new data set named AOlDDl. It is to be on volume 333001 which is 
mounted on a 3330 device. 

3. DD21 defines an old data set named SYSLIB that exists on a private volume, 123456. The 
volume is mounted on a 2314 device. 

4. DD22 defines an old data set named SYSABC that is to be kept after this job step is 
complete. SYSABC is on volume 777777. This volume is to be mounted on the same 
2314 device as the volume defined on DD21. 

5. DD23 defines an old data set named SYSTAPE. There are five volumes that are to be 
mounted only after the data set is opened (caused by the DEFER subparameter). The P 
requests parallel mounting; that is, all five volumes are to be mounted at the same time 
on five different 2400 devices. 

6. DD24 defines an old data named SYSDISK that can be shared by another job since it will 
only be read. It is to be kept after this job step. The number of units used is determined 
by the number of volumes requested. 

7. DD25 is a temporary data set (no DSNAME specified) and therefore, assumes a 
disposition of NEW,DELETE. The volume to be used is the same one used in STEP2 
DD21; that is, volume 123456. 

8. DD26 is also a temporary data set. The backward reference for volume information is to 
STEP2 DD24 where the data set named SYSDISK is located. 



( 



Requesting Space for Non-VSAM Data Sets 

You must request space for every non-VSAM data set created on a direct access volume. To 
request space, code the SPACE parameter on the DD statement that defines the data set. The 
SPACE parameter provides two ways to request space: 

• Tell the system how much space you want and let the system assign specific tracks. 

• Tell the system the specific tracks on which you want the data set written. 



c 
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Letting the system assign specific tracks is the easiest and most frequently used method of 
requesting space. Only the unit of measurement to be used to compute the space requirement 
and how many of the units of measurement the data set requires needs to be specified, x.. 
addition, this form of the SPACE parameter offers several options: 

• A secondary quantity, to be used if the data set runs out of space. 

• Space for a directory or index. 

• Release of unused space. 

• Contiguous space. 

• Whole cyUnders. 

OS/MVT and VS2 Release 1 included the SPLIT and SUBALLOC parameters for requesting 
space for a group of data sets on a single direct access volume. These two parameters are now 
internally converted to SPACE requests. 

The Basic Request: Unit of Measurement and Primary Quantity 

To have the system assign specific tracks, specify only the unit of measurement the system 
should use to allocate space and the primary quantity of space needed. As the unit of 
measurement, you can specify: 

• Average block length of the data, for blocks. 

• TRK, for tracks. 

• CYL, for cylinders. 

As the primary quantity, code an integer, indicating how many blocks, tracks, or cylinders 
are required. 

It is easiest to specify an average block length: the system will allocate the least number of 
tracks required to contain the number of blocks specified. Specifying block length also 
maintains device independence; you can change the device type in the UNIT parameter without 
altering the space request or code a group name that includes different direct access devices in 
the UNIT parameter. 

When specifying TRK or CYL, compute the number of tracks or cylinders required; consider 
I such variables as the device type, track capacity, tracks per cylinder, cylinders per volume, data 
length (blocksize), key length, and device overhead. These variables, and examples of 
estimating space requirements for partitioned and indexed sequential data sets, are described in 
OS/VS Data Management Services Guide. 

Cylinder allocation allows faster input/output of sequential data sets than does track 
allocation. When requesting space in terms of average block length, request that the space 
allocated begin and end on cylinder boundaries: code ROUND as the last subparameter in the 
SPACE parameter. The smallest number of whole cyUnders needed to contain the request will 
be allocated. 

How the System Satisfies Your Primary and Secondary Request 

Enough available space must exist on one volimie to satisfy the primary request. If enough 
space is not available on a single volume, the system will terminate the job or search another 
volume, depending on the type of volume request made: 

Specific volume request (for example, volume serial numbers are specified): If sufficient space 
is not available on the first volume specified, the job is terminated. 
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Nonspecific volume request (for example, the system chooses the volume): If space is not 

available on the first volume chosen, the system will choose another volume and continue the ff 

search, causing volumes to be mounted if necessary, until a volume with sufficient space is 

found or the operator cancels the job. 

The system attempts to allocate the primary and secondary quantity in contiguous tracks or 
cylinders. If contiguous space is not available, the system satisfies the request with up to five 
noncontiguous extents (blocks) of space. (If user labels are specified — that is, you code SUL 
in the LABEL parameter — ^the system allocates up to four noncontiguous extents of space. The 
system allocates a track for user labels separate from the primary quantity; this one track is 
considered an extent, and therefore, up to four additional extents can be allocated to satisfy 
the primary quantity.) 



A Secondary Request for Space 

In the primary quantity, you need not anticipate all future demands for space for a data set. 
Code a secondary request for space to be used only if the data set exceeds its allocated space. 
Do this by coding an integer following the primary quantity that indicates how much additional 
space should be allocated. For data sets whose disposition is NEW or MOD, this space is 
allocated on the same volume as the primary quantity until: (1) there is not enough space 
available on the volume to allocate the secondary quantity, or (2) a total of 16 extents, less 
the number of extents for primary quantity and user label space, have been allocated to the 
data set. (BDAM data sets cannot be extended.) If either of these conditions is satisfied, the 
I system must allocate the secondary quantity on another volume. However, this can be done 
only if you request more than one volume in the VOLUME parameter (for a nonspecific volume 
request, code PRIVATE; for a specific volume request, request more volumes than devices). 

When allocating a secondary quantity for a data set whose disposition is OLD (in other 
words, a data set that is preallocated or is being written over), the system will go to the next ■ 

volume, if one is specified, and see if there is already a secondary quantity allocated there. If ^ 

you did specify another volume and there is already a secondary quantity, the system will use 
that space instead of making another allocation or will allocate space if no space is already 
allocated there for the data set. If you didn't specify another volume, the space will be 
allocated on the current volume. 

A secondary quantity can be requested when creating a data set or when retrieving an 
existing data set, whether or not you coded a secondary quantity in the original request. A 
secondary request for an existing data set is in effect only for the duration of the job step and 
overrides an original request if one was made. 

If you specify SPACE in terms of average block length, code the maximum block length of 
the data in either the DCB macro instruction or the BLKSIZE subparameter of the DCB 
parameter on the DD statement: the system uses the maximum block length to compute how 
many additional tracks to allocate. 

Requesting Directory Space for a Partitioned Data Set 

To create a partitioned data set, request a primary quantity large enough to include space for a 
directory. A directory is an index used by the system to locate members in a partitioned data 
set. It consists of 256-byte records, and you must specify, as the third quantity in the SPACE 
parameter, how many records the directory is to contain. The directory is included in the 
beginning of the primary space, which must be large enough to contain the directory. Request 
enough directory space to allow for growth of the data set: you cannot lengthen the directory 
as you can lengthen the data set itself by requesting a secondary quantity. If the directory runs 
out of space, recreate the data set. For a complete description of the directory, including 
details on member entries that will enable you to compute how many records to request, see 
OS/VS Data Management Services Guide. 
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Requesting Index Space for an Indexed Sequential Data Set 

K you are creating an indexed sequential data set that occupies more than one cylinder, and 
are not defining the index on a separate DD statement, you can request index space in addition 
to a primary quantity. (Request index space as the third quantity in the SPACE parameter. The 
space request for an indexed sequential data set must be in terms of cylinders or absolute track 
allocation.) The system determines whether the request is for a directory or an index by 
examining the DSORG subparameter of the DCB parameter on the DD statement. 
DCB=DSORG=lS or DCB=DSORG=lSU must be included on any DD statement defining an 
indexed sequential data set. 

The index quantity is added to the primary quantity when considering the space 
requirements. 

Assigning Specific Tracks 

You can request that specified tracks on a volume be allocated to a data set. This is the most 
stringent request for space: if any of the tracks requested are occupied, the space cannot be 
allocated and the job is terminated. An example of where specific track allocation is required is 
a data set that is to reside under the fixed heads of a 3348 Model 70F Data Module (cylinders 
1-5). 

To request specific tracks, you must code: 

• ABSTR as the first subparameter, indicating absolute tracks. 

• A primary quantity, specif5mig the number of tracks to be allocated. 

• The relative track number of the first track to be allocated. 

For a partitioned data set, specify how many records you want allocated for a directory. If 
requesting a user-label track, this track will be the first of the space requested. 

If defining ah indexed sequential data set using absolute track allocation, the number of 
tracks for the index, primary, or overflow areas must be equal to an integral number of 
cylinders and on a cylinder boundary. AU of the DD statements defining the indexed sequential 
data sets must request specific tracks. 

Example of Requesting Space 

One purpose of this job is to request space for two temporary data sets. The following steps 
refer to these data sets for volume information. 

( 341 6 , 354 ) , ST0NER,MSGLEVEL=1 ,MSGCLASS=C 

PGM=TESTSYSO 

UNIT=2314,DISP=( ,PASS ) , SPACE=( TRK, ( 10,5)) 

UNIT=3330,DISP=( , PASS ), SPACE=( TRK, ( 10,5)) 

SYSOUT=L 

PGM=TESTSYSO 

DSN=* .STEP1 .DD1 1 ,DISP=( OLD , DELETE , DELETE ) 

V0L=REF=*.STEP1 .DD1 2 , SPACE=( TRK, ( 3,1 ) ),UNIT=3330 

SYSOUT=L 

1. The JOB statement specifies that all job related output is to be printed and that system 
messages for the job are to be written to output class C. 

2. STEPl defines two temporary data sets. Step 2 refers to these data sets for volume 
information. 

3. The space requirements for these requests indicate that for DDll and DD12 in STEPl you 
want 10 primary and 5 secondary tracks; and for DD2 in STEP2 you want 3 primary and 
1 secondary track. 



//ALLOC 


JOB 


//STEPl 


EXEC 


//DD1 1 


DD 


//DD12 


DD 


//SYSABEND 


DD 


//STEP2 


EXEC 


//DD1 


DD 


//DD2 


DD 


//SYSABEND 


DD 
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Mass Storage System (MSS) Considerations 

I Mass storage volumes are accessed on virtual direct access devices. All previously defined 
descriptions of direct access device resource requests apply, with several additional functions 
also available. The mass storage volume device type is 3330V. 

Mass Storage Volume Groups 

The mass storage system (3850) can contain up to 4,720 mass storage volumes (3330V). To 
assist the installation in managing the volumes, the mass storage system utilities are used to 
assign the volumes to groups. When creating a new data set with a nonspecific request, the 
desired group can be specified using MSVGP=id. The system then selects the best volume for 
the requirements from the specified group and causes it to be mounted. 

The installation can define as many groups as necessary; one group and its name are 
standard in all systems (SYSGROUP). The installation then assigns each mass storage volume to 
a user group, SYSGROUP, or to no group. 

Nonspecific Volume Requests for Mass Storage Volumes 

Previously defined descriptions of nonspecific DASD volume requests apply to mass storage 
volumes. The t5rpe of request can be modified by the MSVGP parameter that specifies an 
instaUation defined subset of all mass storage volumes to be used by the system to satisfy the 
request. MSVGP implies a private volume and will always cause a mount of a mass storage 
volume. The system will select a volume from the defined group that has sufficient space to 
satisfy the space requirements of the DD statement. (See the section on mass storage volume 
I control in OS/VS Mass Storage System (MSS) Services for Space Management for the selection of 
MSVGP volumes to satisfy space requirements.) If you code the MSVGP parameter, the 
VOLUME parameter can be used to specify a volume count, but must not be used for volume 
serial numbers. V0LUME=PRIVATE is redundant when MSVGP is used. 

If MSVGP is not specified — 

• when you make a nonspecific request for a private mass storage volume, the system always 
causes a default group of volumes to be used (MSVGP=SYSGROUP). 

• when you make a nonspecific request for a non-private mass storage volume that is to 
contain a temporary data set, the system assigns a public or storage mass storage volume 
that is already mounted. Otherwise, the request is treated as a nonspecific volume request 
for a private volume. 

• when you make a nonspecific request for a non-private mass storage volume that is to 
contain a nontemporary data set, the system assigns a storage mass storage volume, if one is 
mounted. Otherwise, the request is treated as a nonspecific volume request for a private 
volume. 

Specific Volume Requests for Mass Storage Volumes 

Previously defined descriptions of specific DASD volume requests (direct access storage 
volumes) also apply to mass storage volumes. 

Because there is no operator involvement or decision making in mounting mass storage 
j volumes, it is recommended (for data integrity purposes) that all permanent data sets on mass 
storage volumes be cataloged. All specific requests for these data sets should always reference 
the volumes using the catalog, not the VOLUME parameter. Reference to the catalog is required 
when extending an existing multivolume data set to one or more volumes. The reason is that 
the system must know all volumes on which the data set currently resides before it selects the 
new volume. Parallel mounting must also be specified to ensure proper multivolume extensions. 



40 OS/VS2 JCL (VS2 Release 3.7) 



i 



Requesting Space for Non-VSAM Data Sets on Mass Storage Volumes 

When an installation defines mass storage volume groups, each group is given a default for 
space. Specific volume requests for new data sets require the SPACE parameter. Nonspecific 
volume requests with the MSVGP parameter can optionally specify the SPACE parameter. 
Nonspecific volume requests without the MSVGP parameter can optionally specify the SPACE 
parameter if the request will default to MSVGP=SYSGROUP. The space default will always be 
contiguous cylinders. If other types of space attributes are desired, the SPACE parameter can 
be coded to override the specified default. Neither directory nor index quantities can be 
provided in the default; therefore, the SPACE parameter must be coded for new BPAM or ISAM 
data sets on mass storage volumes. 

Before using mass storage volumes, refer to OS/VS Mass Storage System (MSS) Services for 
Space Management. 

Dynamically Allocating and Deallocating Data Sets 

Dynamic allocation allows you to acquire resources as they are needed. One reason to use 
dynamic allocation is that you may not know all of the device requirements for a job prior to 
execution. Another reason is that it allows resources to be used more efficiently; that is, 
resources can be acquired just before their use and/or released immediately after use. 
(Resources, as used here, refer to a ddname-data set combination with its associated volumes 
and devices, if any.) The number of dynamic allocations indicated by coding the DYNAM and 
DYNAMNBR parameters are used to establish a control value for tracking resources held in 
anticipation of reuse. 

You can dynamically deallocate resources during the execution of a job step (at the time the 
data set is closed) by coding the FREE=CLOSE parameter. If you do dynamically deallocate a 
resource at close time, it cannot be reopened in the same step. If you do not want to 
dynamically deallocate the resource, either specify nothing or specify FREE=END to let the 
system deallocate the resources at the end of the job step. 

For more information on how to use dynamic allocation and deallocation, see OS/VS2 
System Programming Library: Job Management. 

Example of Dynamically Allocating and Deallocating Data Sets 



//PROS 


JOB 


CLASS=A,MSGLEVEL=( 2,0), PERFORM=70 


//STEP1 


EXEC 


PGM=TEST , DYNAMNBR=4 , PARM=( P3 , 1 23 , MT5 ) 


//DD1 


DD 


DYNAM 


//DD2 


DD 


DYNAM 


//0UT1 


DD 


SYSOUT=C , FREE=CLOSE 


//OUT 2 


DD 


SYSOUT=A 


//SYS IN 


DD 


* 



data 



1. The JOB statement specifies that this job will be processed in class A in performance 
group 70. Only JCL statements will be printed. 

2. The control value is the total DYNAMNBR and DYNAM parameters coded, in this case, 6. 
If this control value is exceeded and a request for another dynamic allocation is made, 
the request is not honored unless resources can be deallocated so that the control value 
is not exceeded. 

3. When OUTl is closed, it is immediately ready for printing. 
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Id^itifyii^ Data Sets to the System 

Specifying the DDNAME Parameter 

The DDNAME parameter is most often used in cataloged procedures and in job steps that call 
procedures. It is used in cataloged procedures to postpone defining data in the input stream 
until a job step calls the procedure. (Procedures cannot contain DD statements that define data 
in the input stream; that is, DD * or DD DATA statements). It is used in job steps that call 
procedures to postpone defining data in the input stream on an overriding DD statement until 
the last overriding DD statement for a procedure step. (Overriding DD statements must appear 
in the same order as the corresponding DD statements in the procedure). 

When You Code the DDNAME Parameter 

When the system encounters a DD statement that contains the DDNAME parameter, it saves 
the ddname of that statement. The system also temporarily saves the name specified in the 
DDNAME parameter so that it can relate that name to the ddname of a later DD statement. 
Once a DD statement with that corresponding name is encountered, the name is no longer 
saved. For example, if the system encounters this statement 

//XYZ DD DDNAME=PHOB 

the system saves XYZ and, temporarily, PHOB. Until the ddname is encountered in the input 
stream, the data set is a dummy data set. 

When the system encounters a statement whose ddname has been temporarily saved, it does 
two things. It uses the information contained on this statement to define the data set; it 
associates this information with the name of the statement that contained the DDNAME 
parameter. The value that appeared in the DDNAME parameter is no longer saved by the 
system. To continue the above example, if the system encounters this statement 

//PHOB DD DSNAME=NIN, DISP=( NEW, KEEP ),UNIT=2400 

the system uses the data set name and the disposition and unit information to define the data 
set; it also associates the ddname of the statement that contained the DDNAME parameter with 
this information. In this example, the ddname used is XYZ; the ddname PHOB is no longer 
saved. The data set is now defined, just as it would be if you had coded 

//XYZ DD DSNAME=NIN,DISP=( NEW, KEEP ) ,UNIT=2400 

The system associates the ddname of the statement that contains the DDNAME parameter 
with the data set definition information. It does not use the ddname of the later statement that 
defines the data set. Therefore, any references to the data set, before or after the data set is 
defined, must refer to the DD statement that contains the DDNAME parameter, not the DD 
statement that defines the data set. The following sequence of control statements illustrates 
this: 

//DD1 DD DDNAME=LATER 



//LATER DD DSN=SET12,DISP=(NEW,KEEP),UNIT=2314, 
// VOLUME=SER=4623 1 , SPACE={ TRK, (20,5)) 



//DD1 2 DD DSN=SET1 3 ,DISP=( NEW, KEEP ) , VOLUME=REF=* .DD1 , 
// SPACE=( TRK, (40,5)) 



^1 
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When you want to concatenate data sets, the unnamed DD statements must follow the DD 
statement that contains the DDNAME parameter, not the DD statement that defines the data 
set. The following sequence of control statements illustrates this: 

//DDA DD DDNAiME=DEFINE 

// DD DSN=A.B.C,DISP=OLD 

// DD DSN=SEVC,DISP=OLD,UNIT=2314,VOL=SER=52226 



//DEFINE DD * 

data 
/* 

You can use the DDNAME parameter up to five times in a job step or procedure step. 
However, each time the DDNAME parameter is coded, it must refer to a different ddname. 

Specifying the DSNAME Parameter 

When creating a data set, use the DSNAME parameter to assign a name to the data set. The 
data set name is part of the information stored with the data set on a volume. Later, when 
another job step or job wants to use the data set, it identifies the data set name in the 
DSNAME parameter; the system uses the data set name to locate the data set on the volume. 

How you code the DSNAME parameter depends on the type of data set and whether the 
data set is nontemporary or temporary. 

Creating or Retrieving a Nontemporary Data Set 

If the data set is nontemporary, you can identify: 

• A permanent data set by coding DSNAME=dsname. 

• A member of a nontemporary partitioned data set by coding DSNAME =dsname (member 
name). 

• A generation of a nontemporary generation data group by coding 
DSNAME=dsname(number) . 

• An area of a nontemporary indexed sequential data set by coding DSNAME=dsname(area 
name). 

Nontemporary Data Sets 

When a nontemporary data set is created, it is assigned a name in the DSNAME parameter and 
is assigned a disposition of KEEP or CATLG. (A data set assigned a disposition of KEEP may be 
assigned a disposition of CATLG by a later job step or job). The name assigned to a 
nontemporary data set must be specified in the DSNAME parameter by all other steps and jobs 
that want to use the data set. 

A nontemporary data set name can be either an unqualified or qualified name. An 
unqualified data set name consists of 1 through 8 characters. The first character must be an 
alphabetic or national (@,#,$) character; the remaining characters can be any alphameric or 
I national characters, a hyphen, or plus zero (0-12 punch). 

A qualified data set name consists of 1 through 44 characters (including periods), except 
when the qualified name identifies a generation data group. In this case, the data set name 
may consist of only 1 through 35 characters (including periods). For each eight characters or 
less there must be a period, and the first character of the name and the character following a 
period must be an alphabetic or national (@,#,$) character. 
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When requesting a data set that is cataloged on a control volume or a private catalog, the 
system attempts to mount this control volume if it is not already mounted. After the system 
I obtains the pointer to the requested data Set, the control volume or private catalog can then be 
demounted by the system if the unit on which it was mounted is required by another volume. 
The control volume or private catalog is assigned to the job step and is available for 
disposition processing when the job step ends. 

In the following cases, the control volume or private catalog is not mounted when 
disposition is processed: 

• The job fails or abnormally terminates and data sets with a conditional disposition of 
I CATLG or UNCATLG have been passed but not received. 

• A job step is deallocated during system warmstart. 

Members of a Partitioned Data Set 

A partitioned data set consists of independent groups of sequential records, each identified by 
a member name in a directory. When you want to add a member to a partitioned data set or 
retrieve a member, specify the partitioned data set name and follow it with the member name. 
The member name is enclosed in parentheses and consists of 1 to 8 characters. The first 
character must be an alphabetic or national (@,$,#) character, the remaining characters can be 
any alphameric or national characters. 

Generations of a Generation Data Group 

A generation data group is a collection of chronologically related data sets that can be referred 
to by the same data set name. When you want to add a generation to a generation data group 
or retrieve a generation, specify the generation data group name and follow it with the 
generation number. The generation number is enclosed in parentheses and the number is a 
zero or a signed integer. A zero represents the most current generation of the group, a 
negative integer (for example, -1) represents an older generation; a positive integer (for 
example, +1) represents a new generation that has not as yet been cataloged. 

To retrieve all generations of a generation data group (up to 255 generations), code only 
the group name in the DSNAME parameter and the DISP parameter. 

A complete discussion of creating and retrieving generation data sets is contained in 
"Creating and Retrieving Generation Data Sets." 

Areas of an Indexed Sequential Data Set 

The areas used for an indexed sequential data set are the index, prime, and overflow areas. 
When you are creating the data set and define any of these areas on a DD statement, you must 
identify the data set name and follow it with the area name you are defining. The area name is 
enclosed in parentheses and is either PRIME, INDEX, or OVFLOW. If you are using only one 
DD statement to define the entire data set, code DSNAME=dsname or 
DSNAME =dsname (prime). When you retrieve the data set, you code only the data set name; 
you do not include the terms PRIME, INDEX, or OVFLOW. 

Creating or Retrieving a Temporary Data Set 

If the data set is temporary, you can identify: 

• A temporary data set by coding DSNAME= & & dsname. 

• A member of a temporary partitioned data set by coding DSNAME= & & dsname(member 
name). 

• An area of a temporary indexed sequential data set by coding DSNAME= & & dsname(area 
name). 
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Temporary Data Sets 

Any data set that is created and deleted within the same job is a temporary data set. A DD 
statement that defines a temporary data set need not include the DSNAME parameter; the 
system generates one for you. 

If you do include the DSNAME parameter, the temporary data set name can consist of 1 
through 8 characters and is preceded by two ampersands (& & ). The character following the 
ampersands must be alphabetic or national (@,#,$) characters; the remaining characters can be 
any alphameric or national characters. (A temporary data set name that is preceded by only 
one ampersand is treated as a temporary data set name as long as no value is assigned to it 
either on the EXEC statement for this job step when it calls a procedure, or on a PROC 
statement within the procedure. If a value is assigned to it by one of these means, it is treated 
as a symboUc parameter). 

The system generates a quaUfied name for the temporary data set, which begins with SYS 
and includes the JuUan date, the time, the jobname, the temporary name assigned in the 
DSNAME parameter if specified (or an identifying name and number if not specified), and 
other identifying characters. 

If you attempt to keep or catalog a temporary data set (you specify a disposition of KEEP or 
CATLG in the DISP parameter), the system changes the disposition to PASS and the data set is 
deleted at job termination. However, this change is not made for a data set on a tape volume 
when the following conditions exist: (1) the data set is new; (2) the data set is not assigned a 
name; and (3) DEFER is specified in the UNIT parameter. The data set is deleted at job 
termination, but the system tells the operator to keep the volume on which the data set resided 
during the job. To simplify processing of temporary data sets, see "Using Virtual Input/ Output 
(vio) for Temporary Data Sets". If you code a conditional disposition for temporary data sets, 
it is ignored. 

Members of a Temporary Partitioned Data Set 

I When adding a member to a temporary partitioned data set or retrieving a member during the 
job, specify the partitioned data set's temporary name and follow it with the member name. 
The member name is enclosed in parentheses and consists of 1 through 8 characters. The first 
character must be an alphabetic or national (@,$,#) character; the remaining characters can be 
any alphameric or national characters. 

Areas of a Temporary Indexed Sequential Data Set 

The areas used for indexed sequential data set are the index, prime, and overflow areas. When 
you are creating a temporary indexed sequential data set and define any of these areas on a 
DD statement, you must identify the data set's temporary name and follow it with the area 
name you are defining. The area name is enclosed in parentheses and is either PRIME, INDEX, 
or OVFLOW. If you are using only one DD statement to define the enture temporary data set, 
code DSNAME= & & dsname or DSNAME= & & dsname (PRIME). If you want to retrieve the 
temporary data set on the same job, you code only the data set's temporary name; you do not 
include the term PRIME, INDEX, or OVFLOW. 

Associated Data Sets (3540 Diskette) 

Associated data sets are data sets on 3540 diskette volumes that are separate from the job 
stream data set and are to be spooled as SYSIN data sets. Associated SYSIN data sets are 
identified by specifying a data set identifier (on the DD DSID parameter) and, optionally, a 
volume identifier on the DD * or DD DATA statements in the job stream. 
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To have associated data sets merged into the job stream, the job stream containing the 
diskette associated data set requests must be processed by the diskette reader program; it 
cannot be read by either JES2 or JESS. 

Data sets are created on 3540 diskette volumes only by using SYSOUT. The SYSOUT DD 
statement must contain the DSID parameter and a sysout class (or classes) designed by the 
installation to be used by data sets on a 3540 diskette. The diskette writer must be started to 
the sysout class to transfer the data sets to diskettes. 

For more information on the 3540 diskette, refer to OS/VS2 IBM 3540 Programmer's 
Reference. 

Copying the Data Set Name from an Earlier DD Statement 

The name of a data set that is used several times in a job, whether specified in the DSNAME 
parameter or assigned by the system, can be copied after its first use in the job. This allows 
you to easily change data sets from job to job and eUminates your having to assign names to 
temporary data sets. To copy a data set name, refer to an earlier DD statement that identifies 
the data set. When the earUer DD statement is contained in an earlier job step, you code 
DSNAME=*.stepname.ddname; when the earUer DD statement is contained in the same job 
step, you code DSNAME=*.ddname; when the earUer DD statement is contained in a cataloged 
procedure step called by an earlier job step, you code 
DSNAME=*.stepname.procstepname.ddname. 

Specifying the DSNAME Parameter in Apostrophes 

Sometimes, it may be necessary or desirable to specify a data set name that contains special 
characters. If the name contains special characters, you must enclose the name in apostrophes 
(5-8 punch), for example, DSNAME='DAT+5'. If one of the special characters is an 
apostrophe, you must identify it by coding two consecutive apostrophes (two 5-8 punches) in 
its place, for example, DSNAME='DAY"SEND'. A data set name enclosed in apostrophes can 
consist of 1 through 44 characters. 

There are cases when the data set name must contain required special characters, which tell 
the system something about the data set (for example, & & in DSNAME= & & name are 
required special characters that tell the system that this is a temporary data set). In these 
cases, the data set name must not be enclosed in apostrophes because the system will not 
recognize the required special characters as having any special significance. The following data 
set names contain special characters that tell the system something about the data set and, 
therefore, cannot be enclosed in apostrophes: 

• DSNAME=name(member name) 

• DSNAME=name(area name) 

• DSNAME=name(generation number) 

• DSNAME= & & name 

• DSNAME=*.stepname.ddname 

j • Part of, or the entire data set name, that is to be symbolically substituted 

Keep the following rules in mind: 

• If the data set is to be cataloged, the data set name cannot have special characters. 

• If the data set name ends with a blank character, the blank is ignored. 

j • If the only special character is a period, a hj^phen, or plus zero (0-12 punch), you need not 
enclose the data set name in apostrophes. 



i 
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Specifying the LABEL Parameter 

Labels are used by the operating system to identify volumes and the data sets they contain, 
and to store data set attributes. Data sets residing on magnetic tape volumes usually have data 
set labels. If data set labels are present, they precede each data set on the volume. Data sets 
residing on direct access volumes always have data set labels. These data set labels are 
contained in the volume table of contents of the direct access volume. 

A data set label may be a standard or nonstandard label. Standard labels can be processed 
by the system; nonstandard labels must be processed by nonstandard label processing routines, 
which the installation includes in the system. Data sets on direct access volumes must have 
standard labels. Data sets on tape volumes usually have standard labels, but can have 
nonstandard labels or no labels. 

The LABEL parameter must be coded if: 

• You are processing a tape data set that is not the first data set on the reel; in this case, 
indicate the data set sequence number. 

• The data set labels are not IBM standard labels; you must indicate the label t3rpe, 

• You want to specify what type of labels a data set is to have when it is written on a scratch 
volume; indicate the label type. 

• The data set is to be password protected; specify PASSWORD when creating the data set. 

• The data set is to be processed only for input or output and this conflicts with the 
processing method indicated in the OPEN macro instruction; specify IN, for input, or OUT, 
for output. 

• The data set is to be kept for a specific period of time; indicate a retention period (RETPD) 
or expiration data (EXPDT). 

The Data Set Sequence Number Subparameter 

When placing a data set on a tape volume that already contains one or more data sets, specify 
where the data set is to be placed, that is, whether the data set is to be the second, third, 
fourth, etc., data set on the volume. The data set sequence number causes the tape to be 
positioned properly so that the data set can be written on the tape or retrieved. 

The data set sequence number subparameter is a positional subparameter and is the first 
subparameter that can be coded. The data set sequence number is a 1- to 4-digit number. The 
system assumes 1 (this is the first data set on the reel) if you omit this subparameter or code 
0, unless the data set is a passed or cataloged data set. If a data set is cataloged, the system 
obtains the data set sequence number from the catalog; for a passed data set, the data set 
sequence number is obtained from the passing step. 

The Label Type Subparameter 

The label type subparameter tells the system the t3rpe of labels associated with the data set. 
The label type subparameter is a positional subparameter and must be coded second, after the 
data set sequence number subparameter. You can omit this subparameter if the data set has 
IBM standard labels. 

The label type subparameter is specified as: 

SL — if the data set has IBM standard labels. 

SUL — if the data set has both IBM standard and user labels. 

AL — if the data set has American National Standard labels. 

AUL — if the data set has Americal National Standard labels and American National 

Standard user labels. 

NSL — if the data set has nonstandard labels. 

NL — if the data set has no labels. 

BLP — if you want label processing bjrpassed. 

LTM — bypass leading tape mark, if encountered, on unlabeled tape. (OS/DOS interchange) 
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SL or SUL is the only label type that can be specified for data sets that reside on direct 
access volumes. SL, SUL, AL, AUL, NSL, and NL are the only label types that can be specified 
for data sets that reside on tape volumes. BLP and LTM are label type subparameters that can 
also be coded for tape. 

When SL or SUL is specified, or the label type subparameter is omitted and the data set has 
IBM standard labels, the system can ensure that the correct tape or direct access volume is 
mounted. When specif 3dng NSL, installation-provided nonstandard label processing routines 
must ensure that the correct tape volume is mounted. When specif5dng NL or BLP, the operator 
must ensure that the correct tape volume is mounted. If you specify NL, the data set must have 
no standard labels. When specifying AL or AUL, the system ensures that the correct American 
National Standard labeled tape is mounted. 

For cataloged and passed data sets, label type information is not kept. Therefore, refering to 
a cataloged or passed data set that has other than standard labels, code the LABEL parameter 
and specify the label type. 

BLP is not a label type, but a request that the system bypass label processing. This 
specification allows you to use a blank tape or overwrite a seven-track tape that differs from 
the current parity or density specifications. If the bypass label processing option is not selected 
by the installation and you have coded BLP, the system assumes NL. 

Note for BLP: When requesting the system to b5q)ass label processing and the tape volume 
has labels, the system treats anything between tapemarks as a data set. Therefore, in order for 
a tape with labels to be positioned properly, the data set sequence number subparameter of the 
LABEL parameter must be coded and the subparameter must reflect all labels and data sets that 
precede the desired data set. The OS/VS Tape Labels publication illustrates where tapemarks 
appear. 

Nonspeciflc volume request: The label type subparameter can also be specified when making a 
nonspecific volume request for a tape volume (that is, no volume serial numbers are specified 
on the DD statement) and when having a certain type of labels. If the volume that is mounted 
does not have the corresponding label type desired, you may be able to change the label tjrpe. 

When specifying NL or NSL and the operator mounts a tape volume that contains standard 
labels, you can use the volume provided: (1) the expiration data of the existing data set on the 
volume has passed; (2) the existing data set on the volume is not password protected; and (3) 
you make a nonspecific volume request. All of these conditions must be met. If they are not, 
the system requests the operator to mount another tape volume. 

If you specify SL and make a nonspecific volume request, but the operator mounts a tape 
volume that contains other than IBM standard labels, the system asks the operator to identify 
the volume serial number and the volume's new owner before the IBM standard labels are 
written. If the tape volume has American National Standard labels, the system asks the 
operator for permission to destroy the labels. If you specify SL and make a specific volume 
request, but the volume that is mounted does not contain IBM standard labels, the system 
rejects the tape and requests the operator to mount the tape volume specified. 

The PASSWORD and NOPWREAD Subparameters 

The PASSWORD and NOPWREAD subparameters tells the system that you want the data set to 
be password protected. If you specify PASSWORD, the data set cannot be read from, written 
into, or deleted by another job step or job unless the operator can supply the system with the 
correct password. If you specify NOPWREAD (no password read), the data set can be read 
without the operator supplying the password, but the password is still required for writing or 
deleting data sets. 
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The PASSWORD and NOPWREAD subparameters are positional and must be coded third, 
after the data set sequence number subparameter and the label type subparameter or the 
commas that indicate their absence. If you want the data set password protected, specify 
PASSWORD when the data set is created. Password protected data sets must have standard 
labels, either IBM standard or American National Standard labels. 



The IN and OUT Subparameters 

The basic sequential access method (BSAM) permits a specification of INOUT or OUTIN in the 
OPEN macro instruction as the processing method. If you have specified either of these 
processing methods in the OPEN macro instruction and want to override it, you may be able to 
do so by coding either the IN or OUT subparameter. For FORTRAN users, the IN and OUT 
subparameters specify whether the data set is for input or output. 

When INOUT is specified in the OPEN macro instruction and you want the data set 
processed for input only, you can specify the IN subparameter. When the IN subparameter is 
coded, any attempt by the processing program to process the data set for output is treated as 
an error. 

When OUTIN is specified in the OPEN macro instruction and you want the data set 
processed for output only, you can specify the OUT subparameter. When the OUT 
subparameter is coded, any attempt by the processing program to process the data set for input 
is treated as an error. 

The IN and OUT subparameters are positional subparameters. If either is coded, it must 
appear as the fourth subparameter, after the data set sequence number subparameter, the label 
type subparameter, and the PASSWORD subparameter, or the commas that indicate their 
absence. 

The RETPD and EXPDT Subparameters 

When it is necessary that a data set be kept for some period of time you can tell the system 
how long it is to be kept when you create the data set. As long as the time period has not 
expired, a data set that resides on a direct access volume cannot be deleted by or overwritten 
by another job step or job. (If it is necessary to delete a data set, you can use the Access 
I Methods Services DELETE command, as described in OS/VS2 Access Method Services.) 

When the expiration date of a data set is the current date, the data set is considered expired 
and can be deleted or written over by another data set. 

There are two different ways to specify a time period: (1) tell the system how many days 
you want the data set kept, the RETPD subparameter, or (2) tell the system the exact date 
after which the data set need not be kept, the EXPDT subparameter. 

If you code the RETPD subparameter, you specify a 1- to 4-digit number, which represents 
the number of days the data set is to be kept. If you code the EXPDT subparameter, you 
specify a 2-digit year number and a 3-digit day number (for example, January 1 would be 001, 
July 1 would be 182), which represents the date after which the data set need not be kept. 
When neither the RETPD or EXPDT subparameter is specified for a new data set, the system 
assumes a retention period of zero days. 

The RETPD or EXPDT subparameter must follow all other subparameters of the LABEL 
parameter. If no other subparameters are coded, you can code LABEL=RETPD=nnnn or 
LABEL=EXPDT=yyddd. 
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Example of Identifying Data Sets to the System 

This job shows how to use the DSNAME parameter. 



/♦PRIORITY 


8 


//DATASETS 


JOB 


//STEP1 


EXEC 


//D1 


DD 


// 




//D2 


DD 


//D3 


DD 


//D4 


DD 



FREEMAN , MSGLEVEL= 1 

PGM=IEFBR14 

DSN=ABC , DISP=( NEW, CATLG ) , UNIT=23 1 4 , 

VOL=SER=333001 ,SPACE=( CYL, ( 12,1,1 ),CONTIG 

DSN=SSNAME,UNIT=3330,SPACE=(TRK,{ 10,1)) 

DSN=SYSLIB , DISP=( OLD , KEEP ) 

* 



data 



/* 

1. This job runs in priority 8, the meaning of which is defined by the installation. 

2. The job statement specifies that system messages and JCL statements are to be printed. 

3. Dl catalogs a newly created data set. The space request is 12 primary cyUnders, 1 
secondary, 1 directory, and the space is to be contiguous. 

4. D2 creates a temporary data set on a 3330. The space request is for 10 primary tracks 
and 1 secondary. 

5. D3 defines an old cataloged data set. 

6. D4 defines a SYSIN data set. This will be followed by data in the input stream. 

Disposition Processing of Non-VSAM Data Sets 

Disposing of data sets at the end of a job step is known as disposition processing. You request 
disposition processing for non-VSAM data sets by coding the DISP parameter on the DD 
statement defining the data set. (VSAM data sets are handled differently. For information on 
I VSAM, refer to OS/VS2 Access Method Services.) In the DISP parameter, you can code: 

• Data set status as the first subparameter, indicating if the data set is new, is old, can be 
shared with other jobs, or can be lengthened. 

• Normal disposition as the second subparameter, indicating how the data set should be 
handled if the job step terminates normally. 

• Conditional disposition as the third subparameter, indicating how the data set should be 
handled if the job step terminates abnormally. 

If you do not code one of the subparameters, or omit the DISP parameter entirely, the 

I system suppUes default values, as described under "Default Disposition Processing". Refer to 
Figure 25 for further information on disposition processing. 

Specifying Data Set Status 

Indicate a data set's status by coding one of the following: 

• NEW — the data set is being created in this job step. 

• OLD — the data set existed before this job step. 

• SHR — the data set existed before this job step and can be read simultaneously by other 
jobs. 



i 
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• MOD — the system assumes the data set exists and will position the read/ write mechanism 
after the last record in the data set; if the system caimot find volume information for the 
data set, the system assumes the data set will be created in the job step. 

When coding SHR, you are requesting shared control of the data set and the job should be 
reading the data set only. When coding NEW, OLD, or MOD, you are requesting exclusive 
control of the data set. Shared and exclusive control are described in this chapter under 
"Insuring Data Set Integrity". 

Specifying a Disposition for the Data Set 

You can specify one disposition, called a normal disposition, to be used when the job step 
terminates normally (successfully) and another disposition, called the conditional disposition, to 
be used when the job step terminates abnormally. 

For normal disposition, you can request as the second subparameter that the data set be: 

Deleted by coding DELETE. 
Kept by coding KEEP. 
Cataloged by coding CATLG. 
Uncataloged by coding UNCATLG. 
Passed by coding PASS. 

Note: The disposition of a data set is solely a function of the DISP parameter; however, the 
disposition of the volumes on which the data set resides is a function of the volume status 
when the volume is demounted. 

For conditional disposition (the third subparameter of the DISP parameter), you can code all 
of the above with the exception of PASS. 

Data sets allocated to steps that have abnormally terminated and that do not have automatic 
restart are disposed of as specified by the conditional disposition. If a job step abnormally 
terminates during execution and a conditional disposition is not specified, the normal 
disposition is processed. If a job step fails during step allocation: 

• A data set created in that job step is deleted. 

• A data set that existed before that job step is kept. 

Disposition processing differs for data sets on direct access volumes and data sets on 
magnetic tape volumes. A direct access volume contains a volume table of contents (VTOC) 
which consists of control blocks describing the non-VSAM data sets and available space on the 
volume. The handling of tape and direct access volumes when specifying a particular 
disposition is described below. 

When specifying KEEP or PASS for a cataloged data set, the system assumes that you want 
the data set recataloged if volume information was obtained from the catalog and it is 
determined that the catalog entry must be updated. If the job step performs catalog 
maintenance and you wish to avoid recataloging, refer to the data set by its specific unit and 
volume serial when coding the DD statement. 

Deleting a Data Set 

Specifying DELETE requests that the data set's space on the volume be released at the end of 
the job step (when coded as the normal disposition) or if the step abnormally terminates 
(when coded as the conditional disposition). If the data set resides on a public tape volume, 
the tape is rewound and the volume is available for use by other job steps. If the data set 
resides on a private volume, the tape is rewound and unloaded. In this case, it is rewound and 
unloaded and a KEEP message is issued. If the data set exists on a direct access volume, the 
control block describing the data set is removed from the VTOC and the space on the volume 
is then available to other data sets. 
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In one case, however, a data set on a direct access volume will not be deleted, even though 
you specify DELETE: when the expiration date or retention period has not expired. Specify a 
length of time that a data set must be kept by assigning a retention period or expiration date 
in the LABEL parameter on the DD statement. Specifying a retention period or expiration date 
is described under "Specifying the LABEL Parameter". 

If you are deleting a cataloged non-VSAM data set, the entry for the data set in the system 
catalog is also removed, provided the system obtained volume information for the data set 
from the catalog (that is, the volume's serial number was not coded on the DD statement). If 
the system did not obtain volume information from the catalog, the data set is still deleted but 
its entry in the catalog remains. If an error is encountered while attempting to delete a data 
set, its entry in the catalog will not be removed. (The data set will or will not be deleted, 
depending on where the error occurs). Use the Access Method Services DELETE command or 
the lEHPROGM UNCATLG command to delete a non-VSAM entry from the catalog. 

DELETE is the only vaUd conditional disposition for a data set with no name or a temporary 
name. If a disposition other than DELETE is specified, the system assumes DELETE. 



Keeping a Data Set 



Specifying KEEP instructs the system to keep a data set intact until a subsequent job step or 
job requests that the data set be deleted or at least until the expiration date or retention period 
is passed. You can specify an expiration date or retention period, indicating the length of time 
a data set must be kept, in the LABEL parameter on the DD statement. If you do not specify a 
time period, the system assumes a retention period of zero days. Coding an expiration date or 
retention period is described under "Specifying the LABEL Parameter" in this publication. 

If you are assigning a final disposition of KEEP to a passed data set, make certain that the 
rules for receiving a passed data set are followed. See the discussion under "Passing a Data m 

Set" in this chapter. 

For data sets on dkect access devices, the entry describing the data set in the VTOC and the 
data set itself is kept intact. For data sets on tape, the volume is rewound and unloaded and a 
KEEP message is issued to the operator. 



Cataloging a Data Set 



Cataloging allows you to keep track of and retrieve data sets. Data sets can be cataloged in 
the system master catalog or in user (private) catalogs. When retrieving a cataloged data set, 
you do not have to specify volume information, you need only code the DSNAME parameter 
and a status in the DISP parameter other than NEW. 

To catalog a non-VSAM data set, code CATLG as the disposition; the system creates an 
entry in the catalog that points to the data set. The disposition CATLG implies KEEP. 

You can specify a disposition of CATLG for an already cataloged data set. This should be 
done when lengthening the data set with additional output (a status of MOD is coded) and the 
data set can exceed one volume. If the system obtained volume information for the data set 
from the catalog (that is, the volume's serial number was not coded on the DD statement) and 
you code DISP=(mod,CATLG), the system updates the entry to include the volume serial 
numbers of any additional volumes. 

A collection of cataloged data sets that are kept in chronological order can be defined as a 
generation data group (GDG). The entire GDG is stored under a single data set name; each 
data set within the group, called a generation data set, is associated with a generation number 
that indicates how far removed the data set is from the original generation. For more 
information on defining and creating generation data groups, see "Generation Data Groups" in 
this publication, and OS/VS2 Access Method Services. 
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Uncataloging a Data Set 



To remove the entry describing a non-VSAM data set from the catalog, code UNC^'TtG.as the 
disposition. Specifying UNCATLG does not request the initiator to delete the data set — ? lust 
the reference in the catalog is removed. When you request use of the data set in a' subsequent 
job or job step, you must include volume information on the DD statement. ' 

Passing a Data Set ,. 

If more than one step in a job requests the same data set, each step using the data, setcan 
pass the data set for use by a subsequent step. A data set can only be passed within a job.. 

To pass a data set, you code PASS as the normal disposition; PASS cannot be specified as 
the conditional disposition. You continue to code PASS each time the data set is r^erred to^ 
until the last time it is used in the job. At this time, you assign it a final disposition^ 

Specif3dng the data set name of a passed data set without specifying volume serial number 
or a volume reference is called "receiving" the data set. Identical data set- names (wfietlpr or 
not the same data set is referred to) can be passed at the same time. Such identical 43&^ set 
names are received in the same order in which they are passed. A data set name that^Ms been 
passed n times can be received no more than n times. A data set cannot be passed and 
received within the same step. ^ - v 

IFor a description on how the PASS subparameter affects volume disposition, see OS/5^ 
System Programming Library: Job Management. 

Disposition Processing of Unreceived Passed Data Sets 

A data set can be passed by a job step and not subsequently received by another pb<^jep. In 
such a case, if a job step abnormally terminates, unreceived data sets that specified a._ 
conditional disposition when passed are processed as specified in their conditional dispt^tioa, 
with four exceptions. If the conditional disposition requires an update to a user catalog: 

• and CATLG is specified for a data set with a first-level quaUfier of a catalog name.o^r alias, 
the data set will not be cataloged. , . '-y 

• and UNCATLG or DELETE (of a cataloged data set) is specified for a data set .witljia/ \ 
first-level qualifier of a catalog name or aUas, the data set will not be uncataloged: ■ '*. - 

• and CATLG is specified for a data set with no qualifier or with a qualifier thatisiabt^ , 
catalog name, the data set will be cataloged in the master catalog. • , > . 

• and UNCATLG or delete (of a cataloged data set) is specified for a data set with aja : 
qualifier or with a quaUfier that is not a catalog name, an attempt will be^ made ^juaeacalog 
the data set from the master catalog. - - ',^ 

Data sets that do not specify a conditional disposition, that is, those that were specified as 
(new,PASS) in this job, are deleted; all others are kept. 

If no job step abnormally terminates, unreceived data sets that were specified as " ^ 
(new,pass) are deleted; other data sets are kept. 

Default Disposition Processing 

If you do not code the DISP parameter, or omit one of the subparameters, the system supplies 
default values. 

If you do not specify a data set status, the system assumes NEW. If you do not cod^ the 
second or third subparameters, the system determines how a data set should be toijdled 
according to the status of the data set: data sets that existed before the job step are 
automatically kept (data sets for which OLD, SHR, or MOD is coded when volume information 
is available): data sets created in the job step are automatically deleted (data setsi^r which 
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you coded NEW or MOD when volume information is not available, or for which you did not 
code a status). 

If a step abnormally terminates before it actually begins execution (for example, during 
allocation of units and volumes or direct access space), the system ignores the disposition you 
code and again automatically keeps existing data sets and deletes new data sets. 

For example, if you code: 

DISP=( ,PASS,CATLG) 

the system assumes the data set is new. If the job step abnormally terminates during its 
execution, the system will catalog the data set, as instructed by the conditional disposition of 
CATLG. If, however, the step abnormally terminates before it actually begins execution, the 
system will delete the data set, since it is a new data set. 

Bypassing Disposition Processing 

If you define a data set as a dummy data set, the DISP parameter, if coded, is ignored and 
disposition processing is not performed. For details, see "Defining a Dummy Data Set." 

Insuring Data Set Integrity 

When a job must receive control of the data sets it requests, you can request either exclusive 
control, allowing no other job to use the data set, or shared control, allowing the data set to 
be used by other jobs that also request shared control. The process of securing control of data 
sets for use by a job is called data set integrity processing. 

Data set integrity processing avoids conflict between two or more jobs that request use of 
the same data set. For example, two jobs, one named READ and another named MODIFY, both 
request the data set FILE. READ wants only to read and copy certain records, MODIFY deletes 
some records and changes other records in the data set FILE. If both jobs have control of FILE 
concurrently, READ cannot be certain of the records contained in FILE — cannot be sure of 
the integrity of the data set. MODIFY should have exclusive control of the data set; READ can 
share control of FILE with other jobs that also want only to read the data set. Indicate the 
tj^e of control a data set requires in the DISP parameter on the DD statement defining the 
data set. 



Exclusive Control of a Data Set 



When a job has exclusive control of a data set, no other job can use that data set until 
termination of the job that refers to the data set. A job should have exclusive control of a data 
set in order to modify, add, or delete records. 

In some cases, you may not need exclusive control of the entire data set. You can request 
exclusive control of a block of records by coding the DCB, READ, WRITE, and RELEX macro 
instructions. (These instructions are described in OS/VS Data Management Macro Instructions.) 

To request exclusive control of a data set, you code NEW, OLD, or MOD as the first 
subparameter of the DISP parameter. 
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Shared Control of a Data Set 

A data set on a direct access storage device can be used concurrently by several jobs, if these 
jobs request shared control of the data set; however, none of the jobs should change the data 
set in any way. 

To request shared control, you code SHR as the first subparameter in the DISP parameter. If 
more than one step of your job requests a data set, you must code SHR every time you define 
the data set if it is to be used by concurrently executing jobs. Data set integrity processing is 
performed once for a job; a data set has either shared or exclusive control. If you code NEW, 
OLD, or MOD on any reference to a data set, the system assigns exclusive control to the data 
set for the entire job; a reference requesting exclusive control will override any number of 
references requesting shared control. 

How the System Performs Data Set Integrity Processing 

Data set integrity processing is performed for: 

• Nontemporary data sets. 

• Non-vio temporary data sets (see "Using Virtual Input/Output (vio) for Temporary Data 
Sets"). 

• Data sets with alias names (created with the Access Methods Services DEFINE command; 
I see OS/VS2 Access Methods Services.) 

• Members of generation data groups. 

To secure control of a data set for a job, the system enqueues on the data set, marking the 
data set as requested by that job and noting what kind of control was requested. The job will 
receive control of the data set if: 

• The data set is not being used by another job, or 

• The data set is being used by another job but both the job requesting the data set and the 
job using the data set request shared control. 

For example, a job named READ requests shared control of a data set named file; if FILE 
is being used by a job named lookat and lookat also requests shared control, both read 
and LOOKAT can use the data set at the same time. 

A job will not receive control of a data set if: 

• The data set is being used by another job and that job has exclusive control, or 

• The data set is being used by another job (with either exclusive or shared control), but the 
job requesting use of the data set requests exclusive control. 

For example, the job named MODIFY requests exclusive control of the data set file; FILE is 
already being used by the job LOOKAT. MODIFY cannot receive control of the data set until 
LOOKAT has terminated. 

If a job requests data sets that are not available, the system issues the message "JOB IS 
WAITING ON DATA SETS". The initiator that started the job will automatically wait until the 
required data sets become available, unless the operator cancels the job. However, a job will 
fail if it requests a data set with an alias name, or a member of a generation data group, and 
the data set is not immediately available. 



Requestng Resoirces and Identifying Data 55 



Examples of Disposition Processing of Non-VSAM Data Sets 



MSGLEVEL=1 

PGM=IEFBR14 

DSN=ABC,DISP=(SHR,KEEP) 

DSN=SYSA, DISP=( OLD , DELETE , UNCATLG ) 

DSN=SYSB , UNIT=23 1 4 , VOL=SER=23 1401, 

SPACE=(CYL,(4,2,1 ) ) ,DISP={ NEW, KEEP, CATLG 

DSN=SSYS 1 , DISP=( MOD , PASS ) , UNIT=23 1 4 , 

VOL=SER=231404,SPACE=(TRK,( 15,5,1 ) ) 

PGM=IEFBR14 

DSN=S£SYS 1 , DISP=( MOD , DELETE ) , UNIT=23 1 4 , 

VOL=SER=231404,SPACE=(TRK,( 15,5,1 ) ) 



I 



//DISP 


JOB 


//SI 


EXEC 


//D1 


DD 


//D2 


DD 


//D3 


DD 


// 
//D4 


DD 


// 




//S2 


EXEC 


//D1 


DD 


// 





1. The JOB statement requests that all JCL statements and system messages be printed. 

2. Dl in SI defines a data set that already exists and can be shared with other data sets. It 
is to be kept on the volume after this job step. 

3. D2 in SI defines a data set that already exists, cannot be shared with other data sets, is 
to be deleted at the end of the job step, and is to be uncataloged if the program 
abnormally terminates. 

4. D3 in SI defines a new data set that is to be assigned a specific volume (231401) on a 
2314 device. The data set is to be kept on the volume at the end of this job step for 
normal processing but is to be cataloged if the program abnormally terminates. 

5. D4 in SI defines a temporary data set that is to be created in this job step. It is to be 
assigned to volume 231404 on a 2314 device with the space request of 15 primary 
tracks, five secondary, and a directory. This data set is to be passed for subsequent use 
by a job step in this job. 

6. Dl in S2 defines the same temporary data set that was defined in D4 of SI. When this 
step is completed, the data set is to be deleted. 



( 



//PASS 


JOB 


//SI 


EXEC 


//DD1 


DD 


// 




//DD2 


DD 


//DD3 


DD 


//DD4 


DD 


//S2 


EXEC 


//DD5 


DD 


//DD6 


DD 


//DD7 


DD 


//DD8 


DD 


//S3 


EXEC 


//DD9 


DD 



MSGLEVEL=1 

PGM=IEFBR14 

DSN=A,DISP=( NEW, PASS ),VOL=SER=23 1400, 

UNIT=2314,SPACE=(TRK, 1 ) 

DSN=A, DISP=( OLD, PASS ),V0L=REF=*.DD1 

DSN=B , DISP=( OLD , PASS ) , VOL=SER=23 1 400 , UNIT=23 1 4 

DSN=B,DISP=(OLD,PASS),VOL=SER=231401,UNIT=2314 

PGM=IEFBR14 

DSN=A,DISP=OLD 

DSN=A,DISP=OLD 

DSN=B,DISP=OLD 

DSN=B , DISP=( OLD , PASS ) 

PGM=IEFBR14 

DSN=B,DISP=OLD 



1. DDl and DD2 pass the same data set. DD5 and DD6 receive that same data set. 

2. DD3 and DD4 pass different data sets of the same name, DD7 receives the data set 
passed by DD3 and DD8 receives the one passed by DD4. DD8 also continues to pass the 
data set originally passed by DD4. 

3. DD9 receives the data set passed by DD4 and dd8. 



%i 
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Routing a Job Through the System (J£S2 only) 



The operating system interprets JCL statements to determine the resource requirements of jobs 
and job steps. The job entry subsystem 2 (JES2) reads a job into the system, satisfies the 
requirements requested on JCL and JES2 statements, schedules the job, and selects it for 
execution. JES2 automatically performs most of these services for you, but you can code JCL 
and JES2 parameters to influence how these services are performed. For example, JES2 
schedules a job for execution, but you can influence when the job is selected by coding the 
JES2 PRIORITY control statement and the CLASS parameter of the JOB statement. 

This section contains six topics: 

Job Scheduling 

Passing Information to the Job in Execution 

Delaying Job Initiation 

Bypassing Job Initiation 

Conditional Execution of Job Steps 

Restarting a Job 



Job Schedulmg 



The job entry subsystem (JES2) controls the selection of jobs for processing. As JES2 reads a 
job into the system, JCL statements and any input stream data are placed on respective logical 
data sets. The JCL and JES2 statements are checked for syntax errors and appropriate error 
messages are issued. If the JCL statements are syntactically correct, the job is placed on an 
execution queue. The execution queue is divided into job class queues and, within each job 
class queue, jobs are placed according to their priority. Jobs in the same class with the same 
priority are placed on the execution queue in the order they were read into the system. A JES2 
initiator is assigned job classes to process. It selects jobs from the first class assigned to it 
according to the priority of the jobs until no more jobs exist in that class, and then selects jobs 
from the next class assigned. You can influence how a job is placed in the execution 
queue — ^therefore, when it is selected for execution — ^by assigning a job class and priority to 
the job. Do this by coding the CLASS parameter on the JOB statement and the JES2 PRIORITY 
control statement. 

To insure that one job is selected before another or that the desired volumes are mounted 
before a job is executed, delay the job's selection by coding typrun=hold on the JOB 
statement, by coding a job class that will force typrun=hold, or by coding a setup control 
statement. 

The job initiation stage can be entirely bypassed by coding TYPRUN=SCAN or 
TYPRUN=C0PY on the JOB statement or by coding a job class that will force either of these 
options. 

VS2 includes support for controlling the processing rate of jobs and job steps. The 
installation defines a certain number of performance group definitions. Each of these defines a 
particular processing rate formula which is to be used for associated jobs or job steps. To 
associate a job or job step with performance group definitions, code the PERFORM parameter 
on either the JOB or EXEC statements. 



Assigning a Job to a Job Class 



Job classes are established by an installation to group jobs. By assigning jobs to job classes, 
the installation tries to avoid contention between jobs that require the same resources by 
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preventing them from running concurrently and tries to provide a better mix of jobs for more 
efficient system use. The installation determines which characteristics are most important in 
achieving a good balance of jobs in the computing system. Assign a job to a job class by 
coding the CLASS parameter on the JOB statement. 



Assigning a Priority to a Job 

Within a job class, jobs are selected for execution from the execution queue according to job 
priority. Jobs with the same class and priority are placed in the execution queue in a first 
in/first out order. In most cases, JES2 will calculate the job's priority. However, for certain 
jobs, you or the operator can be instructed to assign different priorities. Specify job priority by 
coding a JES2 priority statement. 

Priority is explicitly stated on a PRIORITY statement and used by JES2. The estimated 
nimiber of cards, lines of output, and the time for job execution are used according to 
installation algorithms to calculate the priority, and are also used by JES2 to monitor job 
execution time and output. If these estimates are not stated, installation defaults are assumed. 
If any of these estimates are exceeded, the operator is notified. In some cases, the installation 
can specify that the job be canceled. For example, an installation might specify that the lower 
the estimated execution time and output, the higher the priority. This can enforce correct 
amounts to be specified or the job will be canceled. 

Assigning a Dispatching Priority to Job Steps 

In most jobs, you will want the job's dispatching priority to default to a:n automatic priority 
group (APG) instead of assigning your own dispatching priority. The automatic priority group 
function is an algorithm that the system resources manager will use to attempt to increase 
system throughput by dynamically adjusting the dispatching priority of associated address 
spaces. 

If you do assign a dispatching priority, code the DPRTY parameter on the EXEC statement. 
In the DPRTY parameter, you can code two values. The system substitutes these values in the 
following formula to form the dispatching priority: 

(value 1 X 16) + value2 = step's dispatching priority 

If you omit the DPRTY parameter completely, the job step is assigned the APG priority. If 
value 1 is omitted or it is equal to the apg value, the step is assigned the APG priority and any 
value you code for value2 is ignored. In this case, value2 is obtained from the Installation 
Performance Specification (IPS) using the performance group associated with the job step. (See 
OS/VS2 System Pr<^raiinimig library: InitiaBzation and Timii^ Guide for information on IPS.) If value2 is 
not specified in the IPS, a value of 6 is assigned to value2. 

Performance of Jobs and Job Steps 

You can associate a job or job step with any one of several performance group definitions. 
Performance group definitions which are supplied by the installation, describe the 
workload-dependent processing rate which should be afforded to an associated job or job step. 
Most performance group definitions prescribe good processing rates under light system 
workload conditions. However, when the system workload is moderate or heavy, some 
performance group definitions will specify significantly lower processing rates than for other 
performance groups. The installation defines the number and definition of pert'ormance groups 
needed to meet the response requirements of its various users and will probably pubUsh this 
information for your use. Make the performance group association with the job or job step by 
coding an appropriate performance group number on the PERFORM parameter of the JOB or 
EXEC statement. 
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For further information concerning performance, refer to OS/VS2 System Programming 
Library: Initialization and Tuning Guide and to OS/VS2 System Programming Library: JES2. 
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Passing Information to the Job in Execution 

Some information required by a program can vary from application to application, such as 
module attributes and options required by the compiler, assembler, and Unkage editor 
programs. In order to provide this information to the program at the time it is executed, code 
the FARM parameter on the EXEC statement. The program must include instructions that can 
retrieve this information. (The exact location and format of the information passed to a 
processing program are included in OS/VS2 Supervisor Services and Macro Instructions). 

The FARM parameter can also be coded on the EXEC statement of a cataloged or in-stream 
procedure step. This establishes fields in which you can pass information to the job. By coding 
the FARM parameter on the EXEC statement of the job calling a cataloged or in-stream 
procedure, you can override, add, or nuUify parameters in the procedure or define symbolic 
parameters. For more information on the FARM parameter for these features, see "Cataloged 
and In-stream Procedures." 

Identifying the Program to be Executed 

All executable programs are members of partitioned data sets (hbraries). The Ubrary that 
contains the program can be a temporary Ubrary or a private Ubrary. In order to execute a 
program contained in these Ubraries, code the FGM parameter as the first parameter on the 
EXEC statement. 

Temporary Library 

If in a job you want to assemble, Unkage edit, and then execute a program, make the output of 
the Unkage editor a member of a partitioned data set. This is accompUshed by creating a 
temporary Ubrary. A temporary library is a partitioned data set created in the job to store a 
program as a member of the data set untU it is executed in a subsequent job step. When the 
program is required, refer back to the DD statement that defines the temporary library and the 
member by code FGM=*.stepname.ddname or FGM=*.stepname.procstepname.ddname. You 
can also request use of a program that is a member of a temporary Ubrary by coding 
FGM=program name and including a DD statement named JOBLIB or STEPLIB that defines the 
temporary Ubrary. To keep this program available for use by other jobs, make the program a 
member of a private Ubrary. 



Private Library 



Request use of a program that is a member of a private Ubrary by coding FGM=program name 
and including a DD statement named JOBLIB or STEPLIB that defines the private Ubrary. The 
system automaticaUy looks in the private Ubrary for a member with the corresponding name. 

A program that resides in a private Ubrary can also be executed by coding 
PGM=*.stepname.ddname or FGM=*.stepname.procstepname.ddname. This can be done only 
when the named DD statement defines the program as a member of a private library. 



The IEFBR14 Program 



This program is used to check the syntax of the control statements, aUocate space, or satisfy 
requests for disposition processing prior to execution of a job. To do this, substitute IEFBR14 
for the program name on the EXEC statement. (If you created a data set when using this 
program, the data set's status wiU be old when you execute your own program.) 
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Selecting a Cataloged Procedure Library | 

You can choose which of the installation specified cataloged procedure libraries will be used 
^ - for resolving catalog procedure references in the JCL by coding the PROCLIB parameter on the 
, i , JOBPARM statement. If this parameter is omitted, a cataloged procedure library associated with 
-• your job's class will be used. 

Dela^g Job Initiation 

Although you can influence a job's selection by assigning a job class and priority to the job, 
you cannot predict whether a job in one job class queue will be selected for execution before 
another job in a different job class queue. When jobs exist in the same job class queue, you 
cannot be certain that one job will complete execution before the other job is selected, even if 
you assign a higher priority to the first job. In some cases, when submitting two jobs, JOBA 
and JOBB, JOBA must complete execution before JOBB is initiated — JOBA might create records 
that JOBB will use. JOBB's initiation will have to be delayed until JOBA completes execution. It 
is also possible that resources a job requires will not be available — in this case, you will want 
.to delay the job's initiation until required resources are available. Delay a job's initiation by 
' coding TYPRUN=HOLD on the JOB statement or by specifying a job class defined by the 
installation to force a TYPRUN=HOLD default. You can also delay a job's initiation and have 
specific volumes mounted before the job executes, by coding the SETUP control statement to 
notify the operator which volumes are required. 

To delay a job's initiation, code SETUP, TYPRUN=HOLD, or job class; the job remains on 
the execution queue but cannot be selected for processing until the operator releases the job. 
.When the operator releases the job, it is again eligible for selection according to class and 
' " priority. 

If you code a SETUP control statement, you are able to notify the operator what volumes 
.are to be retrieved from the library. The operator will mount the requested volumes and then 
should release the job. 

Bypassing Job Initiation 

Under certain conditions you may wish to scan the control statements for syntax errors 
without submitting the associated input data sets, or you may wish to produce a copy of your 
input deck without actually initiating any steps. 

To scan the control statements for syntax errors without initiating the job, code 
tYPRUN=SCAN on the JOB statement or select a job class which the installation has defined to 
force the TYPRUN=SCAN default. With this option coded, the job is first scanned for control 
statement syntax errors and then passed directly to the output stage for processing. 

To produce a copy of the input deck without initiating any steps, code TYPRUN=COPY on 
the JOB statement or select a job class which the installation has defined to force the 
TYPRUN=COPy default. With this option coded, the input deck (as submitted) is converted 
directly to a SYSOUT data set and scheduled for output processing. The class of the SYSOUT 
data set is the same as the message class of the job and can be controlled by the MSGCLASS 
parameter on the JOB statement. The SYSOUT data set generated can be processed by either 
the JES2 output processor or by the external writer, but is not available to the TSO OUTPUT 
command. JES2 control statements encountered in the input stream are interpreted before being 
added to the SYSOUT data set; job control language (JCL) statements are copied without any 
processing (that is, no JCL conversion). 
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The operating system interprets JCL statements to determine the resource requirements of jobs 
and job steps. The job entry subsystem 2 (JES2) reads a job into the system, satisfies the 
requirements requested on JCL and JES2 statements, schedules the job, and selects it for 
execution. JES2 automatically performs most of these services for you, but you can code JCL 
and JES2 parameters to influence how these services are performed. For example, JES2 
schedules a job for execution, but you can influence when the job is selected by coding the 
JES2 PRIORITY control statement and the CLASS parameter of the JOB statement. 

This section contains six topics: 

Job Scheduling 

Passing Information to the Job in Execution 

Delaying Job Initiation 

Bypassing Job Initiation 

Conditional Execution of Job Steps 

Restarting a Job 



Job Scheduling 



The job entry subsystem (JES2) controls the selection of jobs for processing. As JES2 reads a 
job into the system, JCL statements and any input stream data are placed on respective logical 
data sets. The JCL and JES2 statements are checked for syntax errors and appropriate error 
messages are issued. If the JCL statements are syntactically correct, the job is placed on an 
execution queue. The execution queue is divided into job class queues and, within each job 
class queue, jobs are placed according to their priority. Jobs in the same class with the same 
priority are placed on the execution queue in the order they were read into the system. A JES2 
initiator is assigned job classes to process. It selects jobs from the first class assigned to it 
according to the priority of the jobs until no more jobs exist in that class, and then selects jobs 
from the next class assigned. You can influence how a job is placed in the execution 
queue — therefore, when it is selected for execution — by assigning a job class and priority to 
the job. Do this by coding the CLASS parameter on the JOB statement and the JES2 PRIORITY 
control statement. 

To insure that one job is selected before another or that the desired volumes are mounted 
before a job is executed, delay the job's selection by coding TYPRUN=HOLD on the JOB 
statement, by coding a job class that will force TYPRUN=HOLD, or by coding a SETUP control 
statement. 

The job initiation stage can be entirely bypassed by coding TYPRUN=SCAN or 
TYPRUN=COPY on the JOB statement or by coding a job class that will force either of these 
options. 

VS2 includes support for controlling the processing rate of jobs and job steps. The 
installation defines a certain number of performance group definitions. Each of these defines a 
particular processing rate formula which is to be used for associated jobs or job steps. To 
associate a job or job step with performance group definitions, code the PERFORM parameter 
on either the JOB or EXEC statements. 



Assigning a Job to a Job Class 



Job classes are established by an installation to group jobs. By assigning jobs to job classes, 
the installation tries to avoid contention between jobs that require the same resources by 
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preventing them from running concurrently and tries to provide a better mix of jobs for more 
efficient system use. The installation determines which characteristics are most important in 
achieving a good balance of jobs in the computing system. Assign a job to a job class by 
coding the CLASS parameter on the JOB statement. 



Assigning a Priority to a Job 

Within a job class, jobs are selected for execution from the execution queue according to job 
priority. Jobs with the same class and priority are placed in the execution queue in a first 
in/first out order. In most cases, JES2 will calculate the job's priority. However, for certain 
jobs, you or the operator can be instructed to assign different priorities. Specify job priority by 
coding a JES2 PRIORITY statement, or by coding the PRTY parameter on the JOB statement. 

Priority is explicitly stated on a PRIORITY statement or JOB statement and used by JES2. The 
estimated number of cards, Unes of output, and the time for job execution are used according 
to installation algorithms to calculate the priority, and are also used by JES2 to monitor job 
execution time and output. If these estimates are not stated, installation defaults are assumed. 
If any of these estimates are exceeded, the operator is notified. In some cases, the installation 
can specify that the job be canceled. For example, an installation might specify that the lower 
the estimated execution time and output, the higher the priority. This can enforce correct 
amounts to be specified or the job will be canceled. 

Assigning a Dispatching Priority to Job Steps 

In most jobs, you will want the job's dispatching priority to default to an automatic priority 
group (APG) instead of assigning your own dispatching priority. The automatic priority group 
function is an algorithm that the system resources manager will use to attempt to increase 
system throughput by dynamically adjusting the dispatching priority of associated address 
spaces. 

If you do assign a dispatching priority, code the DPRTY parameter on the EXEC statement. 
In the DPRTY parameter, you can code two values. The system substitutes these values in the 
following formula to form the dispatching priority: 

(value 1 X 16) + value2 = step's dispatching priority 

If value! is not coded, the system assumes the APG value for the default. (Value2 has a 
default of 11.) If you omit the DPRTY parameter completely or if DPRTY is equal to the APG 
value, the step has the same dispatching priority as the APG value. 

Performance of Jobs and Job Steps 

You can associate a job or job step with any one of several performance group definitions. 
Performance group definitions which are supplied by the installation, describe the 
workload-dependent processing rate which should be afforded to an associated job or job step. 
Most performance group definitions prescribe good processing rates under light system 
workload conditions. However, when the system workload is moderate or heavy, some 
performance group definitions will specify significantly lower processing rates than for other 
performance groups. The installation defines the number and definition of performance groups 
needed to meet the response requirements of its various users and will probably publish this 
information for your use. Make the performance group association with the job or job step by 
coding an appropriate performance group number on the PERFORM parameter of the JOB or 
EXEC statement. 

For further information concerning performance, refer to OS/VS2 System Programming 
I Library: Initialization and Tuning Guide and to OS/VS2 MVS System Programming Library: JES2. 
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Passing Information to the Job in Execution 

Some information required by a program can vary from application to application, such as 
module attributes and options required by the compiler, assembler, and linkage editor 
programs. In order to provide this information to the program at the time it is executed, code 
the FARM parameter on the EXEC statement. The program must include instructions that can 
retrieve this information. (The exact location and format of the information passed to a 
processing program are included in OS/VS2 Supervisor Services and Macro Instructions.) 

The FARM parameter can also be coded on the EXEC statement of a cataloged or in-stream 
procedure step. This establishes fields in which you can pass information to the job. By coding 
the FARM parameter on the EXEC statement of the job calling a cataloged or in-stream 
procedure, you can override, add, or nullify parameters in the procedure or define symbolic 
parameters. For more information on the FARM parameter for these features, see "Cataloged 
and In-stream Procedures." 

Identifying the Program to be Executed 

All executable programs are members of partitioned data sets (libraries). The library that 
contains the program can be a temporary library or a private library. In order to execute a 
program contained in these libraries, code the FGM parameter as the first parameter on the 
EXEC statement. 

Temporary Library 

If in a job you want to assemble, linkage edit, and then execute a program, make the output of 
the linkage editor a member of a partitioned data set. This is accomplished by creating a 
temporary library. A temporary library is a partitioned data set created in the job to store a 
program as a member of the data set until it is executed in a subsequent job step. When the 
program is required, refer back to the DD statement that defines the temporary library and the 
member by code FGM=*.stepname.ddname or FGM=*.stepname.procstepname.ddname. You 
can also request use of a program that is a member of a temporary library by coding 
FGM=program name and including a DD statement named JOBLIB or STEFLIB that defines the 
temporary library. To keep this program available for use by other jobs, make the program a 
member of a private library. 



Private Library 



Request use of a program that is a member of a private library by coding fgm= program name 
and including a DD statement named JOBLIB or STEFLiB that defines the private library. The 
system automatically looks in the private library for a member with the corresponding name. 

A program that resides in a private library can also be executed by coding 
PGM=*.stepname.ddname or FGM=*.stepname.procstepname.ddname. This can be done only 
when the named DD statement defines the program as a member of a private library. 



The IEFBR14 Program 



This program is used to check the syntax of the control statements, allocate space, or satisfy 
requests for disposition processing prior to execution of a job. To do this, substitute IEFBR14 
for the program name on the EXEC statement. (If you created a data set when using this 
program, the data set's status will be old when you execute your own program.) 
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Selecting a Cataloged Procedure Library 

You can choose which of the installation specified cataloged procedure libraries will be used 
for resolving catalog procedure references in the JCL by coding the PROCLIB parameter on the 
JOBPARM statement. If this parameter is omitted, a cataloged procedure library associated with 
your job's class will be used. 

Delaying Job Initiation 

Although you can influence a job's selection by assigning a job class and priority to the job, 
you cannot predict whether a job in one job class queue will be selected for execution before 
another job in a different job class queue. When jobs exist in the same job class queue, you 
cannot be certain that one job will complete execution before the other job is selected, even if 
you assign a higher priority to the first job. In some cases, when submitting two jobs, JOBA 
and JOBB, JOBA must complete execution before JOBB is initiated- — JOBA might create records 
that JOBB will use. JOBB's initiation will have to be delayed until JOBA completes execution. It 
is also possible that resources a job requires will not be available — in this case, you will want 
to delay the job's initiation until required resources are available. Delay a job's initiation by 
I coding TYPRUN=HOLD or TYPRUN=JCLHOLD on the JOB statement or by specifying a job 
class defined by the installation to force a TYPRUN=HOLD default. You can also delay a job's 
initiation and have specific volumes mounted before the job executes, by coding the SETUP 
control statement to notify the operator which volumes are required. 

To delay a job's initiation, code SETUP, TYPRUN=HOLD, TYPRUN=JCLHOLD, or job class; 
the job remains on the execution queue or JCL conversion queue but cannot be selected for 
processing until the operator releases the job. When the operator releases the job, it is again 
eligible for selection. 

If you code a SETUP control statement, you are able to notify the operator what volumes 
are to be retrieved from the library. The operator will mount the requested volumes and then 
I should release the job which has been held on the execution queue. 



Bypassing Job Initiation 



Under certain conditions you may wish to scan the control statements for syntax errors 
without submitting the associated input data sets, or you may wish to produce a copy of your 
input deck without actually initiating any steps. 

To scan the control statements for syntax errors without initiating the job, code 
TYPRUN=SCAN on the JOB Statement or select a job class which the installation has defined to 
force the TYPRUN=SCAN default. With this option coded, the job is first scanned for control 
statement syntax errors and then passed directly to the output stage for processing. 

To produce a copy of the input deck without initiating any steps, code TYPRUN=COPY on 
the JOB statement or select a job class which the installation has defined to force the 
TYPRUN=COPY default. With this option coded, the input deck (as submitted) is converted 
directly to a SYSOUT data set and scheduled for output processing. The class of the SYSOUT 
data set is the same as the message class of the job and can be controlled by the MSGCLASS 
parameter on the JOB statement. The SYSOUT data set generated can be processed by either 
the JES2 output processor or by the external writer, but is not available to the TSO OUTPUT 
command. JES2 control statements encountered in the input stream are interpreted before being 
added to the SYSOUT data set; job control language (jcl) statements are copied without any 
processing (that is, no JCL conversion). 



{ 
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Conditional Execution of Job Steps 

Depending on the results of one step of a job, you may not wish to execute subsequent 
steps — if a compilation fails, you would not want to waste computing time attempting 
subsequent Unk-editing or execution steps. Specify tests to determine whether to bypass or 
execute job steps, based on the results from previous steps by coding the COND parameter on 
either a JOB or EXEC statement. 

The results of a job step can be reflected in a return code, a number from to 4095. The 
COND parameter can be coded to test the return codes which are issued by the compiler, 
assembler, and linkage editor programs. Some return codes are standard for certain programs; 
for example, a return code of 8 issued by a compiler or Unkage editor indicates that serious 
errors were found and execution is likely to fail. In problem programs, assign a number as the 
return code to signify^ a certain condition. For example, if STEPl of a job reads accounts to be 
processed in subsequent job steps, you might set a return code of 10 if no delinquent accounts 
are found. Before STEPS is executed to process delinquent accounts, test the return code from 
STEPl; if the return code from STEPl is 10^ — there are no delinquent accounts — you can skip 
STEP3. Specify the test to check the return code from STEPl by coding the COND parameter. 

You can also instruct the system to execute a step even if a previous step has abnormally 
terminated or only if a previous step has abnormally terminated by coding EVEN or ONLY in 
the COND parameter on a EXEC statement. For example, STEPl of a job updates records in a 
data set. If STEPl abnormally terminates, you want to execute STEP2, which will print the data 
set. Specify that STEP2 should be executed only if STEPl abnormally terminates by coding 
ONLY in the COND parameter on the EXEC statement for STEP2. 

Specifying Return Code Tests 

In the COND parameter, specify tests to determine if the system should bypass a job step. If 
the system determines that a comparison is true, the job step is skipped (if COND was coded 
on the EXEC statement) or all remaining job steps are skipped (if COND was coded on the JOB 
statement). 

For example, if you code COND=((10,GT),(20,LT)), you are asking, "Is 10 greater than the 
return code or is 20 less than the return code?" 

If the return code is 12, neither test is satisfied: no job step is skipped. All the tests you 
specify must be false if processing is to continue without skipping any job steps. If the return 
code is 25, the first test is still false, but the second test is satisfied: 20 is less than 25. The 
system will bypass one job step or all remaining job steps, depending on if the COND 
parameter was coded on the EXEC statement or on the JOB statement. 

Restarting a Job 

When a job step abnormally terminates, you may have to resubmit the job for execution; this 
means lost computer time and a delay in obtaining the desired results. The operating system 
provides restart facilities to reduce the effects of abnormal termination. 

There are two types of restarts: 

• Step restart, from the beginning of a job step. 

• Checkpoint restart, from a checkpoint within a job step. (You estabUsh checkpoints in a job 
step by coding the CHKPT macro instruction for each checkpoint. The CHKPT macro is 
described in OS/VS Data Management Macro Instructions.) See also the DD CHKPT parameter. 
It specifies that checkpoints are to be taken at end of volume for the data set defined by 
the DD statement on which it is coded. 
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Whether using step restart or checkpoint restart, the restart facility can be automatic or jii 

deferred. ^ 

Automatic restart: To use automatic restart, code the RD (restart definition) parameter on the 
JOB or EXEC statement. If you use this facility, the presence of a job journal is required. (A 
job journal is established at JES2 initialization in order to hold restart information for each 
program in execution.) When a system failure occurs or a job step abnormally terminates and 
you have a job journal, the restart facility allows you to have automatic restart by coding 
RD=R on the JOB or EXEC statements. If you have taken checkpoints, automatically restart at 
the last checkpoint regardless of whether you have coded the RD parameter. When a job step 
abnormally terminates or a system failure occurs while the job is in execution and you do not 
have a job journal, these jobs are ineligible for automatic restart regardless of whether or not 
the RD parameter is coded. 

Deferred restart: To use deferred restart, code the RESTART parameter on the JOB statement. 
This required parameter specifies a job step or a step of a cataloged procedure and can specify 
a checkpoint identifier if you are using deferred checkpoint restart. The effect of the parameter " 
is simply to restart the job at the beginning of the specified step or checkpoint. The SYSCHK 
DD statement is required when a job is being submitted for deferred checkpoint restart and 
must specify explicit UNIT and VOLUME information even if the checkpoint data set is 
cataloged. 

Refer to OS/VS Checkpoint/Restart for a complete description of planning for and using the 
checkpoint restart facility. 



Example of Routing a Job Through the System (JES2 only) 

The purpose of this job is to execute five steps to perform an unspecified function. Not all of 
the steps will execute because conditions are placed on them. 

(D58706),ROEGER,MSGLEVEL=( 1,1 ),CLASS=E 

PGM=IEFBR14 

SYSOUT=A 

PGM= I EFBR 1 4 , COND=EVEN 

SYSOUT=A 

PGM-IEFBR1 4 , COND=ONLY 

SYSOUT=A 

PGM=ABEND806 

SYSOUT=A 

PGM=IEFBR1 4 , COND^ONLY 

SYSOUT=A 

1. This job will use the installation-defined priority default. 

2. The JOB statement specifies that only JCL statements and messages are to be written, 
that the job is assigned to job class E. 

3. All SYSOUT data sets will be processed by output class A. 

4. STEPl will execute normally. 

5. STEP2 will execute normally. 

6. STEPS will not execute. 

7. STEP4 will execute and will abnormally terminate. 

8. STEP5 will execute because a preceding step did abnormally terminate. 



/♦PRIORITY 


* 


//ROUTE 


JOB 


//STEPl 


EXEC 


//DD1 


DD 


//STEP2 


EXEC 


//DD2 


DD 


//STEPS 


EXEC 


//DD3 


DD 


//STEP4 


EXEC 


//DD4 


DD 


//STEPS 


EXEC 


//DD5 


DD 
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Obtaining Output (JES2 only) 



By coding JCL statements, you can request output data sets, listings of JCL statements, system 
messages, and abnormal termination dumps. By coding JCL and JES2 statements, you can 
request special forms processing, routing of output to specific devices, and multiple original 
printing by data sets within a job. The JES2 statements have the same options as JCL with 
some additional features such as multiple destination, left and right indexing feature for the 
3211 printer, and data set grouping. 

This section includes four topics: 

• Requesting Listings of JCL Statements and System Messages 

• Requesting an Abnormal Termination Dump 

• Writing Output Data Sets 

• Controlling Output Destination 

Requesting Listings of JCL Statements and System Messages 

The system produces messages about a job concerning allocation of units and volumes, 
disposition of data sets, and termination of job steps and the job. You can request that these 
messages and/or the JCL statements from the job and from cataloged procedures called by the 
job be included on an output listing. 

By coding the MSGLEVEL parameter on the JOB statement, you inform the system of what 
statements and messages you want included on the output listing. (The notation used on the 
output listing to identify cataloged and in-stream procedure statements is described in the 
chapter "Using Cataloged and Tn-stream Procedures.") 

By coding the MSGCLASS parameter on the JOB statement, you assign messages and JCL 
statements to an output class. A default is assigned if MSGCLASS is not coded. 

Requesting an Abnormal Termination Dump 

To obtain a dump in the event of abnormal termination of a job step, code a DD statement 
defining a dump data set. The name of the DD statement must be either SYSABEND or 
SYSUDUMP. If both DD statements are present, the first one is used. 

The SYSABEND or SYSUDUMP DD Statements can provide a dump containing the processing 
program's virtual storage area, the system nucleus, the entire system queue area, all local 
system queue areas, and any active link pack area (lpa) modules for the failing task. If the 
generalized trace facility (GTE) is active in the system and performing an internal trace, you 
receive GTE trace records. If GTE is active but performing an external trace, no trace 
information is included in the dump. Determine what dump features are wanted in addition to 
the installation defaults and define them in a dump option list. How to do this is explained in 
OS/VS2 System Programming Library: Supervisor. 

Dumps with more data per page are available with the 3800 Printing Subsystem. By 
specifying CHARS=DUMP on the related DD statement, the dump is formatted in a 
204-character line containing 64 bytes of storage. If ECB=STD3 is specified, the page is printed 
at 8 lines per inch. The dump program recognizes only STD3 for producing 8 lines per inch. 

Descriptions of dumps and information on reading dumps are included in the OS/VS2 System 
Programming Library: Debugging Handbook. 
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To have the dump printed, either assign the dump to an output class in the SYSOUT 
parameter on the DD statement or code the UNIT parameter and specify the printer you want. 
To store the dump, define the data set as you would any other data set, coding the DSNAME, 
DISP, UNIT, and VOLUME parameters. If the data set will go to a direct access device, code the 
SPACE parameter. 
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If a private data set is specified and more than one dump is possible, the data set should be ■ 

specified with a disposition of MOD as it will be closed after each dump. 

Writing Output Data Sets 

There are two ways to write output data sets: 

• Assign the data set to an output class. 

• Specify the device on which the output should be written. 

When you assign a data set to an output class, it is handled by JES2. The data set is first 
written to the JES2 spool device and then written to the final output device by either JES2 or 
an external writer. When you specify the device on the UNIT parameter, if the device is 
available, it is exclusively assigned to your job and under the control of your program. 

Output data sets to be written to a 3540 diskette must be assigned to an output class that is 
processed by the diskette writer (an external writer) as described in OS/VS2 IBM 3540 
Programmer's Reference. 

Assigning Output Data Sets to Output Classes 

Output classes include output with similar characteristics that are written to the same device. 
There are 36 possible output classes that can be coded on either the SYSOUT or MSGCLASS 
parameters. The letter and number names have no inherent meaning; — each installation defines 
its own output classes. For example, output class W might contain low priority output; class X 
might be reserved for high-volume output. If you want the output data set and messages from 
the job to be printed on the same output listing, specify SYSOUT=* or the same output class in 
the SYSOUT parameter as specified for messages in the MSGCLASS parameter. 



The installation can designate certain SYSOUT data sets as reserved. Reserved classes can 
cause the data sets to be held; that is, not sent to JES2 output processing. If the output class 
specified for the MSGCLASS parameter is not designated as a reserved class, it will not be held 
and none of the job's data sets assigned to reserved classes will be held. Data sets can be 
explicitly held by coding the HOLD=YES parameter or by coding TSO commands. (Refer to 
OS/VS2 TSO Command Language Reference for information on the TSO commands.) Jobs can be 
released from the hold state by the operator or by the time-sharing user with the OUTPUT TSO 
command. By using reserved classes, the controUing of the holding or not holding of all desired 
print data sets is done by means of the MSGCLASS parameter on the JOB statement. 



Specifying the Device 



To write an output data set without using the JES2 SYSOUT service, code the UNIT parameter 
on the DD statement defining the device on which the data set is written. The system will 
allocate the device exclusively to the job if the device is available: no other job can write 
output to that device until it is released. Jobs cannot share an output device as they can when 
output is assigned to output classes. 

Data management routines write the output from the program to the device specified in the 
UNIT parameter. Specifying a particular output device in the UNIT parameter generally is not 
the most efficient method for obtaining system output. 



Processing Output Classes 



Using JES2 is an efficient way to write output. JES2 supports the use of local and remote 
printers and punches as devices on which output classes are written. An external writer 
supports tape and direct access devices and user- written writer routines. 
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Job related output is output that is neither held nor spun off nor processed by a 
user- written writer. (A spun off data set is made available for output processing before job 
termination.) Job related output will be retained until the end of the job and printed by JES2. 
Ail dynamically deallocated SYSOUT data sets are spun off and, as with held output, are not 
considered part of the job related output. 

Output will be printed on the same listing if such parameters as CLASS, FORMS, FCB, UCS, 
and DEST have similar characteristics for all data sets and a user-written writer is not specified. 
The installation may choose to put all data sets that specify the same output class as the 
MSGCLASS parameter out on the same listing, even though FORMS, UCS, FCB, and DEST are 
different. 

For an external writer, the operator will determine what data set will be selected. This can 
cause certain output to print out on the same listing even though all of the FORMS, DEST, ucs. 
and FCB parameters do not indicate the same characteristics. 

Either an IBM-supplied external writer or a user-written writer can process the output. The 
external writer must be started by the operator to have the data written to an output device. If 
you want to know more about how to write an external writer routine, refer to OS/VS2 System 
Programming Library: Job Management. 

Delaying the Writing of an Output Data Set 

Data sets can be delayed from normal printing or delayed for inspection from a time sharing 
terminal prior to actually printing on that terminal by specifying reserved classes and by coding 
the HOLD parameter. For example, the installation can direct the delayed printing of a very 
large data set to prevent monopolizing an output device until smaller data sets are written. If a 
data set requires special forms that are not immediately available, it can be held until the 
operator supplies those forms. When HOLD=YES is specified on the DD statement, the data set 
is placed on a hold queue until the operator releases it. Notify the operator (using the NOTIFY 
parameter for TSO or the MESSAGE statement for JES2) when that data set is ready for 
processing because no message will be sent to the operator. The data set can be released by 
the operator or time-sharing user for printing. 

Suppressing the Writing of an Output Data Set 

Whether writing an output data set by coding the SYSOUT parameter or the UNIT parameter, 
you can suppress the writing of the data set by defining it as a dummy data set. This is useful 
when testing a program and you do not want data sets printed until you are sure they will 
contain meaningful output. Suppressing the writing of a data set saves processing time. 

If you are routing an output data set by coding the SYSOUT parameter, code the DUMMY 
parameter to define the data set as a dummy data set. When DUMMY is coded, the SYSOUT 
parameter is ignored and the data set is not written. 

You can also suppress the writing of an output data set by specifying a particular 
installation-defined class defined to delete the data set before it is printed. This technique is 
used by the installation to suppress the output of started tasks such as START and MOUNT 
commands. 

If the device on which the data set will be written is specified in the UNIT parameter, you 
can assign the data set a dummy status by coding DUMMY or by assigning the data set name 
NULLFILE. All parameters other than DUMMY or DSNAME=NULLFILE and DCB'are ignored; 
no units are assigned to the data set. When the program requests that the data set be written, 
the request is recognized but no data is transmitted. The facility is available by use of the basic 
sequential access method (bsam) or queued sequential access method (QSAM) in a request to 
write a dummy data set. If any other access method is used, the job is terminated. 
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Limiting Output Records 

The number of logical records in the output data set can be limited by specifying a maximum 
number of records through the use of the OUTLIM parameter. For example, a program is 
printing and goes into an endless loop. You can anticipate this problem and only have a 
maximum number of records printed before having the system discontinue the output 
processing. 

Requesting Page Overflow Processing 

JES2 will automatically limit the number of lines printed per page, thus preventing printing over 
the edge of the form, if requested either by the installation during JES2 initialization or by the 
programmer coding LINECT or the JOBPARM statement. The installation specified number of 
lines per page can be overridden by the JOBPARM LINECT parameter or line limiting can be 
turned off by coding LINECT=0. Set the line count sufficiently large to prevent unwanted page 
ejects for output from programs that provide page eject carriage control parameters. 

Interpretation of Punched Output 

Cards punched on a 3525 card punch from output spooled by JES2 will be interpreted if you 
code FUNC=I as a DCB subparameter on the SYSOUT card and if the spooled output is 
processed by a JES2 writer rather than the external writer. The FUNC=I subparameter will be 
ignored if the spooled output is processed by the JES2 writer onto a card punch other than the 
3525. You could check with the installation to determine if a special output class has been set 
aside for 3525 output. Card interpretation by the external writer is an operator specified 
function. Output to be interpreted should be placed in a class designated by the installation as 
a punch with interpretation class. 

JES2 Support of the 3211 Indexing Feature 

You can specify that output that is printed by the JES2 writer onto* a 3211 printer be indexed 
to the right or to the left by coding the INDEX or LINDEX parameters, respectively, on the 
OUTPUT statement. These parameters will be ignored if the output is processed by the external 
writer or is processed to a device other than a 32 11. Determine whether an output class has 
been set aside to designate output to be processed by a JES2 writer onto a 32 11 printer by 
asking the installation's system programming staff. 

Requesting Multiple Copies of an Output Data Set 

You can control the number of hard copies produced by the SYSOUT data sets. As many as 
255 copies of an output data set are obtained by coding the COPIES parameter on the SYSOUT 
DD statement defining the data set or on the JES2 OUTPUT control statement. As many as 255 
copies of the entire job related output are obtained by coding the COPIES parameter on the 
JES2 JOBPARM control statement. 

If you request multiple copies of job related output by coding the OUTPUT or SYSOUT DD 
statements and the JOBPARM control statement, JES2 output processing will give the multiple of 
the requested amount for each SYSOUT data set. For example, if you request two copies of the 
entire job output (code COPlES=2 on the JOBPARM statement) and three copies of a certain 
output data set (code COPIES =3 on a SYSOUT DD statement or output control statement), 
you will receive two copies of the entire job output but will receive a total of six copies of the 
SYSOUT data set. If the data set has been written directly to an output device, held, spun off, 
or processed by an external writer, however, it is no longer a job related data set and is not 
affected by the COPIES parameter on the JOBPARM statement. In this example, you would 
receive three copies of the requested output data set. 
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With the 3800 Printing Subsystem, you can also specify on the SYSOUT DD statement how 
the copies of the output data set are to be grouped. Each group value of the COPIES parameter 
specifies the number of copies of each individual page that is to be printed before copies of 
the next page are printed. The total number of copies printed equals the sum total of the 
group values. Group values can also be coded on the COPYG parameter of the JES2 OUTPUT 
statement. 



Requesting Copy Modification 



Selected copies of output can be modified when using the 3800 Printing Subsystem by 
specifying a copy modification module name on the MODIFY parameter of the SYSOUT or 
output DD statement or on the JES2 OUTPUT statement. This allows the printing of predefined 
data on all pages of a specific copy or copies of a data set. For example, you may want to 
vary column headings or explanatory remarks on different copies of the same printed page of 
data. Copies might also be personaUzed with the recipient's name, address, and other desired 
information. Blanks or printable characters such as asterisks, might also be used to suppress 
the printing of variable data on particular copies of a page. (This is a function done in other 
printers by using short or spot carbon in the forms set.) 

The predefined data is created as a copy modification module and stored on SYSI.IMAGELIB 
using the lEBIMAGE utility program. For information on using lEBIMAGE, see the IBM 3800 
Printing Subsystem Programmer's Guide. 
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Requesting Printer Form and Character Control 

When requesting that an output data set be printed, you can give JES2 special instructions on 
how to print the data set. You can request: 

• A special output form. 

• A special character set or arrangement, when output is being printed by a 3211 or 1403 
printer with the universal character set feature or by a 3800 Printing Subsystem. 

• A specific FCB (forms control buffer) module, which controls how many lines per inch are 
printed and the length of the form, when the data set is written to a 3211 printer or a 3800 
Printing Subsystem. 

• A specific carriage control tape, when the data set is written to a 1403 printer. 

Requesting a Special Output Form 

Special forms are requested for output data set printing by including the form name in the 
SYSOUT parameter on the DD statement defining the data set or by coding the FORMS 
parameter on the OUTPUT control statement. For example, assign a data set to an output class 
to be routed to a printer and specify the data set be printed on a special form. (For example, 
code SYS0UT=(A„FMS2).) JES2 and the external writer insure that the proper form is mounted. 

The entire job can be printed on a special form by coding the FORMS parameter on the 
JOBPARM statement. If you code a forms name on either the SYSOUT or the OUTPUT 
statements, it overrides the forms name in the JOBPARM statement. 

Requesting a Special Character Set Using the UCS Feature 

The universal character set (UCS) feature is requested by coding the UCS parameter on a DD 
statement defining an output or SYSOUT data set or by coding UCS on the OUTPUT control 
statement for SYSOUT data sets. You can request the UCS feature for different sets of 
characters to be printed for various apphcations. 

To request a special character set for a 3211 or 1403 printer, specify the code identifying 
the character set in the UCS parameter or the OUTPUT statement. The codes for the IBM 
standard special character sets are in Figure 10. 



1403 


3211 


Characteristics 


AN 
HN 

PCAN 
PCHN 

PN 
QN 
RN 

SN 
TN 
XN 
YN 


All 
HU 
GU 

PU 
Til 


Arrangement A, standard EBCDIC character set, 48 characters 

Arrangement H, EBCDIC character set for FORTRAN and COBOL, 48 characters 

ASCII character set 

Preferred alphameric character set, arrangement A 

Preferred alphameric character set, arrangement H 

PL/I alphameric character set 

PL/I preferred alphameric character set for scientific applications 

Preferred character set for commercial applications of FORTRAN and COBOL 

Preferred character set for text printing 

Character set for text printing, 120 characters 

High-speed alphameric character set for 1403, Model 2 

High-speed preferred alphameric character set for 1403, Model 3 or Nl 



Figure 10. Special Character Sets for the 1403 and 3211 Printers (JES2) 

Note: Where two values exist (for the 1403 and 3211 printers), either can be coded and JES2 
selects the set corresponding to the device on which the data set is printed. 

Not all of these character sets may be available at your installation. In addition, the 
installation can design character sets to meet special needs and assign a unique code to them. 
See the system programming staff for a complete list of available character sets for the 
installation. 
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Requesting Character Arrangements with a 3800 Printing Subsystem 

Character arrangement tables to be used when printing with the 3800 are specified with the 
CHARS parameter on the SYSOUT or output DD statement or on the JES2 OUTPUT statement. 
The table names supplied for the 3800 are given in Figure 28 A. See your system programmer 
for the selection of table names available at your installation. 

When more than one character arrangement table is specified, you can code OPTCD=J as a 
DCB subparameter to indicate that your data line contains a table reference character for 
dynamically selecting the table you want. (See the description of the OPTCD subparameter for 
BSAM and QSAM in the topic, "The DCB Parameter".) Using the lEBlMAGE utility program, 
you can modify or construct character arrangement tables and graphic character modification 
modules to allow substitution of existing or user-designed characters. Details for using both 
lEBIMAGE and the OPTCD subparameter are provided in the IBM 3800 Printing Subsystem 
Programmer's Guide. 

The UCS (universal character set) parameter can be specified on the same output DD 
statement with the CHARS parameter to permit output to go to either the 3800 or to other 
printers. The GFlO, GF12, or GF15 character arrangement table coded on the CHARS parameter 
provides the same effect as the FOLD subparameter of UCS. If a printer other than the 3800 is 
allocated, the CHARS parameter is ignored. 

Requesting Forms Control 

For a 1403 Printer: Forms control is requested by specifying a. specific carriage control tape in 
the FCB parameter on the OUTPUT control statement. Carriage specifications are used for JES2 
output processing only; they are ignored by the external writer. 

For a 3211 Printer: Specific forms control images (for example, the number of lines per page I 

or number of characters per line) are requested by coding an image identifier in the FCB 
parameter on a DD statement or by coding FCB on the OUTPUT control statement. The FCB 
image is stored on SYSl.IMAGELIB. IBM provides two standard FCB images: STDl and STD2. 
STDl specifies that 6 lines per inch are to be printed on an 11 -inch form. STD2 specifies that 8 
lines per inch are to be printed on an 8. 5 -inch form. (Do not specify STDl or STD2 for JES2 
processing unless instructed by your installation.) Additional FCB images can be specified by 
the installation. For information on IBM- and user-supplied FCB images, see OS/VS2 System 
Programming Library: Data Management. 

For a 3800 Printing Subsystem: Forms control is requested by specifying an FCB module name 
in the FCB parameter on a DD statement or on the OUTPUT control statement. (Although the 
FCB image for the 3211 and the FCB module for the 3800 serve the same purpose, they are 
constructed differently and are not interchangeable between the two printers.) The FCB module 
is stored on SYSl.IMAGELIB. IBM provides a standard FCB module, STD3, which specifies 
output of 80 lines per page at 8 lines per inch on 11 -inch long paper. (For a 3800 using ISO 
paper sizes, STD3 can be redefined by the installation.) Additional FCB modules can be 
specified by the installation. For information on IBM- and user-supplied FCB modules, see the 
IBM 3800 Printing Subsystem Programmer's Guide. 

Requesting Forms Overlay 

The forms overlay feature of the 3800 Printing Subsystem allows printing of the image from a 
forms overlay negative together with the data being printed. This reduces the need for 
pre-printed forms, and for changing of forms. The FLASH parameter on the DD statement or 
the FLASH and FLASHC parameters on the JES2 OUTPUT statement identify the overlay to be 
used and the number of copies on which that overlay is to be printed. For information on 
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designing and making or obtaining forms overlay negatives, see the Forms Design Reference 
Guide for the IBM 3800 Printing Subsystem. 

Bursting of Output 

The optional Burster-Trimmer-Stacker of the 3800 Printing Subsystem separates continuous 
form paper into individual sheets. The BURST parameter on the DD statement or on the JES2 
OUTPUT statement is used to specify to the operator whether the output is to go to the 
Burster-Trimmer-Stacker or to the continuous forms stacker. For further information and 
examples, see the topic, "The BURST Parameter". 

ControUing Output Destination 

JES2 allows you to submit jobs to a central computing center from a work station and to route 
output to work stations. 

The default output location is the submitting location, either a remote work station or the 
central site (-destination of LOCAL). To receive the output at the submitting location, simply 
assign output data sets to any output class (with the SYSOUT parameter) and messages from 
your job to an output class (with the MSGCLASS parameter). At remote stations, JES2 offers 
most of the same options for writing data sets that are requested when submitting the job at 
the central computing center. You can request: 

• That a data set be held until the operator requests that it be printed. 

• That a special output form be used by specifying a form name in the SYSOUT parameter. 

• That multiple copies of the data set be used. 

Whether at a remote station or at the central computing center, you can also request that a 
data set be routed to another destination. To route an output data set to another destination, 
code the identification of that destination in the DEST parameter on the DD statement defining 
the data set or code DEST on the OUTPUT statement. If you code a destination on either the 
SYSOUT or the OUTPUT statements, it will override the destination in the ROUTE statement. 
Work stations are identified by a destination identification that has been estabhshed by the 
system programmer. The destination parameter will cause output to be routed to local printers 
or punches or to any remote station. 

Example of Obtaining Output (JES2 only) 

This example shows the use of JES2 and JCL statements that can be used to obtain output. 

/♦PRIORITY 5 

//OUTJOB JOB BAKER, PERF0RM=1 00, MSGCL.ASS=J 

/*JOBPARM C0PIES=2 , LINECT=20 , ROOM=233 , F0RMS=GRN1 

/*OUTPUT PSET DEST=PRINTER8,FCB=STD3,FORMS=2PRT,UCS=TN 

/*SETUP SCHLIB 

//STEP1 EXEC PGM=TESTSYSO 

//DD1 DD DSN=DATA,UNTT=2314,VOL=SER=SCHLIB, 

// DISP=( OLD, KEEP ),SPACE=(TRK,( 5,2 ) ) 

//DD2 DD DSN=£TEMP,UNIT=2 314,DISP=( NEW, DELETE ) , 

// SPACE=(TRK,( 10,5 ) ) 

//DD3 DD SYSOUT=( A, ,PSET) 

//DD4 DD SYSOUT=( A, ,GRPH) 

//DD5 DD SYSOUT=L 
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1. The job will be selected at priority level 5. 

2. The job will run in performance group 100; the meaning of 100 is defined by the 
installation. All system messages are to be written to output class J. 

3. The JOBPARM statement indicates that: 

a. Two copies of the entire job related output will be printed. 

b. No more than 20 lines per page will be printed (LINECT=20). 

c. The programmer's office number is 233. This appears on the separator page and is 
used for distributing output. 

d. Forms name GRNl is the name of the form to be used by all data sets unless a specific 
form is defined on a DD statement. 

4. The OUTPUT statement indicates that: 

I a. PSET is the code that, when indicated on a SYSOUT DD statement, causes all 
parameters on the OUTPUT statement to override default parameters. 

b. The destination for the output is a printer and is number 8 if it is local print/punch 
routing; otherwise, PRI^fTER8 is equilvalent to LOCAL. 

c. If the printer has the forms control buffer feature, STD3 must be the name of a 
member of SYSLIMAGELIB. std3 defines the special forms control buffer image to be 
used for processing the job. 

d. Forms name 2PRT is the name of the forms for data sets coding PSET in the SYSOUT 
parameter. 

e. TN means text printing on a 1403 printer. 

j 5. The SETUP statement indicates that volume SCHLIB should be mounted before this job 
begins processing. 

). SYSOUT data sets and message class are printed on the form called GRNl except DD3 
and DD4. The DD4 SYSOUT data set is printed on the form called GRPH; the DD3 
SYSOUT data set is printed on the form called 2PRT, since the code name subparameter . 
of DD3 contains the value PSET (referring to the /*OUTPUT statement). 
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Routing a Job Through the System (JES3 only) 



The job entry subsystem 3 (JES3) reads a job into the system, satisfies the requirements 
requested on JCL and JES3 statements, optionally preschedules JES3 supported devices, selects 
the job for execution, and controls the processing of SYSOUT data sets. JES3 automatically 
performs most of these services, but by coding JCL and JES3 parameters you can influence how 
these services are performed. For example, JES3 schedules a job for execution but you can 
customize how and when the job is processed by coding one or more of the parameters on the 
JES3 MAIN statement. The MAIN SYSTEM parameter is used to direct a job to a specific 
processor in a loosely-coupled multiprocessing environment and the MAIN SETUP parameter is 
used to modify JES3 device selection algorithms. In a loosely-coupled multiprocessing system, 
processors are connected by channel-to-channel adapters that pass information to the JES3 
system operating on each processor. Shared direct access devices, which are read by the global 
and local processors, contain JES3 and system control blocks, and user data. One processor, the 
global, controls job selection for all processors in the system. The other processors are local 
processors and/or MVT or VS2/1 systems that are configured as ASP main processors. For the 
ASP main processors, SYSIN and SYSOUT processing is done through the channel-to-channel 
adapters. 

To ensure that one job is executed before another, use dependent job control (DJC). To 
attempt job scheduling by a certain time, use deadline scheduling (MAIN DEADLINE). To hold 
a job for any other purpose, such as availability of input data, code TYPRUN=HOLD on the 
JOB statement or use the HOLD parameter on the MAIN statement. 

MVS includes support for controlling the processing rate of jobs and job steps. The 
installation defines a certain number of performance groups. Each of these defines a particular 
processing rate to be used for associated jobs or job steps. To associate a job or job step with 
an MVS performance group, code the PERFORM parameter on either the JOB or EXEC 
statements. 

This section contains six topics: 

Scheduling a Job 

Selecting a Processor 

Allocating Devices 

Selecting a Job 

Passing Information to the Job in Execution 

Restarting a Job 



Scheduluig a Job 



JES3 controls the selection of jobs for processing. When a job is read into the system, it is 
initially placed on a spooling disk pack. The JCL and JES3 statements are checked for syntax 
errors and if they are correct, JES3 determines allocation requirements for the job. JES3 device 
selection takes place next. Devices are selected based on device requirements for JES3-managed 
devices established in the JCL. Any necessary volumes that require mounting are requested. 
(More information on this subject is found in the Allocating Devices section.) Once all 
JES3-managed devices are selected and the first volume on each device is mounted (unless 
deferred mounting is requested or implicit high watermark setup is used), the job is placed in 
the queue for execution. (Implicit high watermark allocates a minimum number of devices to 
run a job.) 
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When JCL or JES3 statements have syntax errors, appropriate error messages are issued and 
the job is terminated. When the job has JES3 allocation errors, error messages are issued and 
execution is bypassed. 

The execution queue is logically divided into groups of job classes specified by the 
installation and within each job class group, jobs are placed according to their job priority. 
Jobs in the same job class group with the same job priority are placed in the execution queue 
in the order they were read into the system. The various job class groups are assigned priorities 
by the installation. JES3 starts system initiators on each processor and assigns them a job class 
group to process based on the installation priorities. It selects jobs from any class assigned to 
it. Jobs are selected by job class, processor eligibility, workload balancing, and priority order as 
described in the section, "Selecting a Job". 



Selecting a Processor 



JES3 usually automatically selects a processor for a job based on device, volume, and data set 
dependencies known to it. However, if any of the dependencies are not known to JES3, the job 
can be processed incorrectly or can fail. The next section, "Allocating Devices," discusses 
these dependencies in more detail. There can also be processor dependencies; that is, a special 
system feature such as an emulator, non-standard catalog, or system-managed device, that JES3 
will not recognize unless you define which processor or control program is required on the 
SYSTEM and TYPE parameters on the MAIN statement. The MAIN SYSTEM parameter specifies 
the processor and the MAIN TYPE parameter specifies the control program for the job. 

The MAIN SYSTEM subparameters, JGLOBAL and JLOCAL, request a specific VS2 processor; 
ASP requests an ASP main processor. To specify particular processors or exclude particular 
processors, code the main-name value on the MAIN SYSTEM parameter for each processor. 

The MAIN TYPE subparameters, MVT and VS2/1, request a specific control program on an 
ASP main processor; VS2 requests a specific control program for either a global or local 
processor. 

It is not necessary to specify both SYSTEM and TYPE unless you want to exclude particular 
processors. For example, TYPE=VS2,SYSTEM=/x indicates that the job can execute on any VS2 
processor except x. 

Not all classes are eligible to run on all processors; therefore, make sure that the job class 
for the job is eligible before selecting a specific processor. 

A job is flushed if it specifies a job class (on the JOB or MAIN statements) and a specific 
processor(s) (on the SYSTEM and TYPE subparameters on the MAIN statement) that are 
incompatible. A processor(s) is defined for each valid job class on the CLASS initialization 
statement during JES3 initialization. For example, if a job specifies CLASS=C and SYSTEM=SY1, 
then the processor SYi must have been defined on the CLASS initialization statement for class 
C. 



Allocating Data Resources 



Data resources, that is, devices, data sets, and volumes that are required for each DD request, 
are allocated either by JES3 or by the system according to DSNAME, DISP, UNIT, and VOLUME 
on the DD statement. If your data set is an existing data set and specifies or requires a unit 
managed by JES3, JES3 will allocate the request on a job basis before the job executes by 
examining the request in relation to other data requests in this and other jobs. Otherwise, the 
system will allocate the request on a step basis as the step enters execution. 



I 



i 
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Devices are divided into three catagories in a JES3-controlled system: system-managed, 
jointly managed, or JES3-managed. The following chart indicates what type of devices are 
eligible for each type of allocation. 



How Managed 


Attribute of Device 


Permanently Resident 


Removable 


System-managed 


X 


X 


Jointly managed (JES3/MVS) 


X 




JES3-managed only 




X 



JES3 allocation (job setup, high watermark setup, and explicit setup explained later in this 
topic) will utiUze JES3-managed devices and jointly managed devices. System allocation will 
utilize system-managed and jointly managed devices. The system programmer defines the 
devices that are in each category managed either jointly or by JES3. Refer to "Requesting 
Units and Volumes" earlier in this book for a brief discussion of system allocation. Refer to 
OS/VS2 System Programming Library: Job Management for additional information on system 
allocation, and OS/VS2 System Programming Library: JES3 for more information on JES3. 

Types of JESS Setup 

JES3 supports three types of setup: job setup, high watermark setup, and explicit setup. 

I Job setup. Job setup results in allocation of all JES3-managed units required in the job. If you 
specify SETUP=JOB on the MAIN statement, JES3 will mount the initial volumes necessary to 
run all steps before the job executes. When volumes are no longer needed, they will be 
demounted and the devices deallocated (made available for use by another job). If the 
FREE=CLOSE DD parameter is specified, the deallocation takes place when the data set is 
closed. 

High watermark setup. High watermark setup attempts to allocate a minimum number of 
devices to run the job. SETUP=THWS, SETUP=DHWS, and SETUP=HWS on the main statement 
define whether the high watermark setup is for tapes, disks, or both. When volumes are no 
longer needed, they can be demounted and the devices deallocated (made available for use by 
another job). If the FREE=CLOSE DD parameter is specified, the deallocation takes place when 
the data set is closed. When it is advantageous to use fewer devices for a job, high watermark 
setup is preferable to job setup. In Figure 11, volume A is mounted for use in STEP! and then 
demounted when not in use until needed in STEP4. Volume K is mounted for use in STEPl and 
STEP2 and then demounted when not in use until needed in STEP4. Volumes A and K are 
mounted in STEP4 on any available device. 

Explicit setup. ExpUcit setup is user directed and can, for ASP main processors only, allocate 
more than the minimum number of devices requested to run the job, sometimes eliminating 
remounts of volumes. For MVS main processors, explicit setup uses the number of units 
required by job setup, but premounts volumes according to the expUcit setup specifications. 
SETUP =ddname or SETUP =/ddname on the MAIN statement specifies expUcit setup and the 
ddname request to be setup or to be removed from consideration for setup. An advantage of 
explicit setup over high watermark setup is that volumes can be forced to remain mounted on 
devices until they are no longer needed. However, there is one disadvantage if expUcit setup is 
specified: there is no early deaUocation of devices. Job setup and high watermark setup can 
deallocate devices at the end of any step if the devices are no longer needed. ExpUcit setup, 
however, aUocates a certain number of devices before job execution and does not deaUocate 
any until the job completes execution. 
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In Figure 11, four devices are allocated for both tape and disk instead of the three allocated 
using high watennark setup. By explicitly requesting that certain volumes be mounted, volumes 
A and K can avoid being deallocated and remounted for the last step. 



Devices and Volumes to be Allocated 



Three Types of JESS Setup 



Job Setup 
(SETUP=JOB) 



Tape 



Disk 



High Watermark 

Setup^ 
(SETUP=HWS) 



Tape 



Disk 



Explicit Setup 
(SETUP=ddname) 



Tape 



Disk 



Volumes on Devices Set Up Prior to 
Execution 



Steps in a Job^ 

ST EP 1 tape vol u nie=A , B 
disk volume=K, L 



STEP2 tape volume=B, C, D 
disk volume=K 



STEPS tapevolume=D 

disk volume=L, M, N 



STEP4 tape volume=A, E, F 
disk volunne=K. N, O 



Total devices used by the job for setup 



M 



M 




c 



6 Tape 



5 Disk 



3 Tape 



3 Disk 



4 Tape 



4 Disk 



LEGEND: 



The device is allocated and in use 

The device is allocated but not in use 

The device is no longer needed and can be deallocated 



^High waternnark setup can express combinations of tape and disk allocations. 
HWS request allocation of the minimal number of devices required to run the job. 
THWS requests high watermark setup for tapes and job setup for disks. 
DHWS requests high watermark setup for disks and job setup for tapes. 



^Volumes mounted after STEP1 are indicated by placing the volume name in the 
box for the step in which it is allocated. For example, in high watermark setup, 
volume C is mounted at STEP2. 



Figure 11. Example of JES3 Setup 
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To avoid holding devices until the step needs them for any of the forms of JESS allocation, 
use dependent job control. See the topic, "Dependent Job Control," later in section to 
determine how to split a job into smaller, dependent jobs for execution. 



Selecting a Job 



Jobs are selected for execution according to processor eUgibiUty, job class, job processing 
balancing, and priority order. A job must first be eligible for a particular processor, then 
selection is by class (as defined by installation criteria) and optionally by workload 
characteristics and by priority. Processor eligibiUty is discussed in the section, "Selecting a 
Processor." 

AssJ^niii^ a job to a job class. A job class is a description of the type of job being submitted; 
that is, production, testing, and so forth. It is established by the installation and has no 
inherent meaning except as the installation has defined it. It is used by the installation for 
scheduling jobs on eligible processors. To assign a job to a job class, code the CLASS 
parameter on the JOB statement or the CLASS parameter on the MAIN statement. If neither of 
these parameters are coded, the job wiU be assigned an installation-defined standard class 
default. 

Establishing job processmg balance. The MAIN lORATE parameter specifies a value for the job 
to determine the mix of jobs for each processor. It defines the relationship between CPU-bound 
processing and l/0-bound processing for that job which is expressed as being high, medium, or 
low I/O. JES3 attempts to provide a balance of CPU-bound and l/O-bound jobs to improve the 
scheduUng of jobs for execution. The MAIN lORATE parameter regulates how a job is 
scheduled as contrasted with the PERFORM parameter on either the JOB or EXEC statement 
that regulates how a job executes. The PERFORM parameter is discussed in the section, 
"Performance of Jobs and Job Steps." 

Asis%iiiii^ a priority to a job. Within a job class group, jobs are selected for execution 
according to job priority. Jobs with the same priority are placed in a first m/first out order. 
Specify job priority by coding the PRTY parameter on the JOB statement. 

The priority order for jobs can be changed by the operator, by priority aging, or by deadline 
scheduling. How the operator changes priority is discussed in Operator Library: OS/VS2 
Reference (JES3). 

Priority aging allows JESS to increase the priority of a job after it has been passed over by 
JESS an installation-specified number of times. A job can be bypassed because of an 
insufficient number of devices or contention for a volume or data set or because there is not 
enough main storage on an MVT main processor. The installation defines priority aging; it 
cannot be specified using JCL. 

Deadline scheduUng allows you to specify a time of day when the job should be scheduled. 
If the job is not scheduled by this time, JESS will increase the priority of the job at 
installation-defined intervals until it is scheduled. For more information on deadline scheduling, 
refer to the next section. 

In addition to job selection, raising a job's priority will cause the job to be given preferential 
treatment in JESS device selection. For more information on JESS device selection, see 
"Allocating Devices." 



Deadline Scheduling 



When a job must be scheduled by a certain time of the day, week, month, or year, specify this 
on the MAIN DEADLINE parameter. By indicating that there are time restrictions, you influence 
the priority of the job and help insure that the job wiU be scheduled when necessary. For 
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example, a job must be scheduled every Friday by 2 p.m. to calculate the pajrroll. Request that 
the job be scheduled by that time by coding //*MAIN DEADLINE=(1400,A,6,WEEKLY). The 
subparameter values mean the following: 

1400 is 2 p.m. on a 24-hour clock. 

A defines the deadline type that determines the periodic increment of the job's priority (the meaning for A 

is defined by the installation). 
6 is the sixth day of the week (the first day is Sunday; the seventh day is Saturday). 
WEEKLY is the cycle indicating the frequency of scheduling this job. 

The purpose of deadline scheduling is to allow submission of a job at its true priority level 
and have JES3 schedule it to best use the available resources. The priority level will be 
increased only if the job is not scheduled on time. For example, if you work first shift and 
submit a job at the end of the day, you do not need results until the next morning. Indicate 
that the job must be scheduled by 7 a.m. and assign an initial lower priority, then the job can 
be scheduled at any time. If it has not been scheduled a few hours before the 7 a.m. deadline, 
the priority will be increased periodically to increase the job's chances for being selected by 7 
a.m. 

If you have requested that a job be scheduled by a certain time on a certain day and the 
job is submitted after the deadline time, the priority of the job is incremented to the same 
level it would have been if it had been submitted prior to the deadline and not completed. 

Postponing Job Selection 

It is possible that resources other than those managed by JES3 will not be available; for 

example, you may want to read a job before all input is available. In this case, delay the job's 

selection by coding TYPRUN=HOLD on the JOB statement or HOLD=YES on the MAIN 

statement. When delaying a job's initiation, the job remains on the selection queue but cannot j 

be selected for processing until the operator releases the job. Notify the operator when to ■ 

release the job on the JESS OPERATOR statement or on the JCL command statement. When the 

operator releases the job, it is again eUgible for selection. 

Performance of Jobs and Job Steps 

To regulate the execution performance of a job, associate a job or job step with a performance 
group. The installation defines performance groups that determine the rate at which a given 
job will have access to the CPU, storage, and I/O channels. Most performance groups designate 
good processing rates under light system workload conditions. However, when the system 
workload is moderate or heavy, some performance groups will have significantly lower 
processing rates than others. The installation defines the performance groups needed to meet 
the response requirements of its various users and will probably publish this information for 
your use. Associate the performance group with a job or job step by coding a performance 
group number on the PERFORM parameter on the JOB or EXEC statements. The PERFORM 
parameter regulates how a job executes as contrasted with the MAIN lORATE parameter that 
regulates how a job is scheduled. The MAIN lORATE parameter is described in the section, 
"Selecting a Job." 

For further information concerning system performance, refer to OS/VS2 System 
Programming Library: Initialization and Tuning Guide. 

Assigning a Dispatching Priority to Job Steps 

For most jobs run on MVS, the job's dispatching priority will default to an automatic priority 
group (APG) instead of being assigned. The automatic priority group function is an algorithm 
that the system resources manager will use to attempt to increase system throughput by 
dynamically adjusting the dispatching priority. 
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If you do assign a dispatching priority, code the DPRTY parameter on the EXEC statement. 
This parameter has two values that the system uses in the following formula to calculate the 
dispatching priority: 

( valuel X 16) + value2 = step's dispatching priority 

If you omit the DPRTY parameter completely, the job step is assigned the APG priority. If 
valuel is omitted or it is equal to the APG value, the step is assigned the APG priority and any 
value you code for value2 is ignored. In this case, value2 is obtained from the Installation 
Performance Specification (IPS) using the performance group associated with the job step. (See 
OS/VS2 System Programming Library: Initialization and Tunii^ Guide for information on IPS.) If value2 is 
not specified in the IPS, a value of 6 is assigned to value2. A job run on an ASP main 
processor can have the dispatching priority be the default execution priority. 

Execution Priority (for ASP Main Processors only) 

If JPRTY=JOB is coded on the MAIN statement, the execution priority default is the sanie as the 
value specified in the PRTY parameter of the JOB statement. If JPRTY=JES3 is coded on the 
MAIN statement, the PRTY parameter on the JOB statement is ignored. The default execution 
priority is the value of DPRTY specified on the SELECT initialization statement. A job run on 
MVS ignores any JPRTY value. 

Dependent Job Control 

Dependent job control (DJC) is used when jobs must be executed in a specific order 
determined by job dependencies. There are several reasons for requiring one job to process 
before another. For example, in JES3, data set information is fetched from the catalog before 
the job is scheduled. If JOBA changes or adds to a catalog that JOBB wiU refer to, use 
dependent job control to ensure that JOBA runs before JOBB is processed by JES3 allocation. 
Another reason for using DJC is to achieve better device utilization. If a job requires only one 
device for the first four steps but requires five devices for the fifth step, break the job into two 
jobs (one for the first four steps and one for the fifth step). Use DJC to make the second job 
dependent on the first; that is, the second job can run only after the first job has completed. 
DJC is also useful in controlling the scheduling of jobs that have data dependencies. 

To define a dependent job net, submit a NET statement with each job. The NET statement 
identifies a job's net and specifies the dependency that must be satisfied before the job can be 
scheduled. Jobs normally must wait for scheduling until a predecessor job completes. Jobs that 
depend on one or more predecessor jobs to complete are called successor jobs. To specify the 
number of predecessor/successor relationships of a given job in a net, specify the number of 
predecessor jobs on the NHOLD parameter and the name of each successor job in the RELEASE 
parameter of the NET statement. The number of predecessors is the number of jobs 
immediately prior to the job dependent upon other jobs completing; the number of successors 
is the total number of all jobs remaining to be processed in the net that depend on this job 
completing. 

A normal or abnormal predecessor completion can be the requirement estabUshed for going 
to the next job. For example, JOBAB might not be requested unless the predecessor job 
abnormally terminates. The NORMAL and ABNORMAL parameters on the NET statement 
specify the kind of predecessor completion required for the successor dependent job to 
execute. 

The number of immediate predecessor jobs that must complete before a job is released for 
scheduling, including jobs from another network that are predecessors to the dependent job, 
are specified on the NHOLD parameter. When this parameter is defined, the job is placed into 
dependent job control hold status when it enters the system. A job is made eligible for JES3 
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allocation and scheduling when its NHOLD count, which is decremented when each predecessor 
job completes execution or by the operator, becomes zero. However, the NHOLD value can be 
decremented before the predecessor job completes execution by issuing a special WTO 
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(write-to-operator) command in the predecessor job problem program. Refer to OS/VS2 
Supervisor Services and Macro Instructions, for the format of the write-to-operator command. 

To place jobs in operator hold that are in a dependent job net, code the NET OPHOLD 
parameter. This parameter action prevents scheduling of the job until it is explicitly released 
from hold by the operator. 

Upon either normal or abnormal completion of a predecessor job, a successor job can have 
its NHOLD count decremented, can be flushed from the system, or can be retained pending 
operator action. If it is flushed, the job and aU of its successor jobs (and their successor jobs) 
are canceled, printed, and flushed from the system. If it is retained in the system in the held 
state, the NHOLD count is not decremented and the job and all of its successor jobs are 
suspended from scheduUng until either the predecessor is resubmitted or the operator 
decrements the NHOLD. You can control external dependencies by setting the NHOLD value 
one greater than normally assigned and asking the operator to decrement the NHOLD count 
when the dependency is satisfied. 

Early setup of successor job resources is indicated on the RELSCHCT parameter. It allows a 
job to enter JES3 allocation before all precedessor jobs have completed. The job is then placed 
in a hold status until all of its predecessors complete processing. Early setup of successor job 
resources is invoked when the NHOLD count becomes less than or equal to the RELSCHCT 
count. This option must not be used with jobs that have catalog dependencies. Coding the 
RELSCHCT parameter can tie up devices and data sets for an extended period of time, so it 
should be used carefully. 

Dependencies can be established between jobs in different nets. To indicate that a job in 
one network is the predecessor to a job in another network, specify the NETREL parameter. 
See the of dependent job control example on the following pages to show the use of the 
NETREL parameter. 

Devices can be dedicated to a dependent job net by coding the DEVPOOL parameter. When 
the DEVPOOL parameter is coded in the first job in a net, (it is ignored if not coded in the first 
job) the devices specified are dedicated for device allocation and volume mounting only by 
jobs in the same net. To release these devices prior to all jobs completing in the network, code 
the DEVRELSE parameter. This parameter may be specified on one or more jobs in the net, 
except the first job. The first completing job that contains DEVRELSE=YES will cause the 
dedicated devices to be released. If no such job is encountered, the devices are released when 
the net is purged. 



How to Code NET Statements 



When a job is part of a net, the number of predecessor jobs and the names of all successor 
jobs must be indicated on the NET statement. A diagram is a good way to graphically show the 
relationship of jobs in a net. Once a net of dependent jobs have been described in a diagram, 
the dependencies can be listed in a table and then translated into NET statements. (See the 
following three examples.) The following is a guideline for defining dependent job control nets: 

1. Draw a diagram of the net, connecting dependent jobs with lines indicating the flow of 
job dependencies. Give the net a name (such as EXAMl) to identify the net; this 
becomes the NETID parameter value. 

2. List the jobname of each job in the net in the order of their dependencies on one 
another. Note next to each jobname the number of predecessors to the job, including 
predecessors of other job-nets, if applicable. The number of predecessors becomes the 
NHOLD parameter value. If early setup scheduling is desired, specify it as RS=count 
(RELSCHCT=count) where count specifies setup of a dependent job's resources before 
all of its predecessors have completed execution. 
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3. List the disposition of each successor jobname based on normal or abnormal predecessor 
completion. 

4. List the successor jobnames for each job in the diagram. If there is a successor in a 
different net, then list the successor jobname and successor net-id in parentheses. The 
successors become the RELEASE parameter values. 

5. Construct the necessary NET statements based on the diagram. 

One way to verify the net is to execute the IEFBR14 program for each job in the net, 
simulating normal and abnormal completions. The general format for each job of the net is: 

//jobname JOB 

//*NET your specific parameters 

//STEP1 EXEC PGM=IEFBR14 

/* 
In this way, aU DJC net functions and definitions can be tested without using actual jobs. 



Examples of Dependent Job Control 



Instead of coding the full name of the parameters for every job, the short form of the 
following parameters can be used. 

Parameter Short Form 

NETID ID 

NHOLD HC 

RELEASE RL 

NORMAL NC 

ABNORMAL AB 

OPHOLD OH 

RELSCHCT RS 

NETREL NR 

1. A simple net 

Given: five jobs. A, B, C, D, and E. 

NETID Jobname Predecessors Successors 

EXAMl (NHOLD) (RELEASE) 

job C 

job C 
2 jobs D,E 

1 none 
D) (E) E 1 none 

How to code EXAMl: 

Jobname Control Statement 

A //*NET NETID = EXAMl, RELEASE = (C) 

B //*NET NETID = EXAM 1, RELEASE = (C) 

C //*NET NETID = EXAM 1, NHOLD = 2,RELEASE = (D,E) 

D //*NET NETID = EXAM 1, NHOLD =1 

E //*NET NETID = EXAM i, NHOLD =1 

If the system scheduled this net of jobs with defined dependencies, the desired sequence 
could be achieved only through operator action. By using JES3 dependent job control, operator 
intervention is not required. Jobs A and B can run concurrently, followed by job C, and then 
jobs D and E can run concurrently. 
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2. Multiple predecessor jobs 

Given: six jobs, A, B, C, D, E, and F 
the NETID is EXAM2. 
Jobname 




Predecessors 


Successors 


Disposition 


(NHOLD) 


(RELEASE) 







jobs CD 







jobs C,D,E 


AB = R (retain job) 

NC = D (decrement job) 


2 


job F 


AB = R (retain job) 

NC = D (decrement job) 


2 


job F 


AB = F (flush job) 

NC = D (decrement job) 


1 


job F 


AB = R (retain job) 

NC = D (decrement job) 


3 


none 


AB = R (retain job) 

NC = D (decrement job) 



NETID 
EXAM2 

A 
B 

C 

D 

E 

F 

How to code EXAM2: 

Jobname Control Statement 

A //*NET NETID = EXAM2,RELEASE = (C,D) 

B //*NET NETID = EXAM2,RELEASE = (C,D,E) 

C //*NET NETID = EXAM2,RELEASE = (F),NHOLD = 2 

D //*NET NETID = EXAM2,RELEASE = (F),NHOLD = 2,ABN0RMAL = F 

E //*NET NETID = EXAM2,RELEASE = (F),NHOLD = 1 

F //*NET NETID = EXAM2,NH0LD = 3 

If either job A or B abnormally terminates, job D is flushed from the system and causes job 
F to be flushed. Jobs C and E remain in the system. In this situation, the predecessor should 
be corrected and resubmitted to the system. When it completes normally, its successors, C and 
E, are made eligible for scheduling. 

3. Complex network 

Given: two networks, EXAM4 and EXAM3. 

EXAM4 contains four jobs, W,X,Y, and Z. 

EXAM3 contains ten jobs, A,B,C,D,E,F,G,H,I, and J. 

The net to be released (NETREL) for job I is EXAM4, the release jobname is Y. 



c 




Jobname 



w 

X 



Predecessors 
(NHOLD) 


1 



Successors 
(RELEASE) 

jobX 
job Y 

jobZ 

none 



Disposition 



AB = R (retain job) 

NC = D (decrement job) 

AB = F (flush job) 

NC = D (decrement job) 

AB = F (flush job) 

NC = D (decrement job) 
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(S) 



EXAMS Jobname Predecessors Successors Disposition 

(NHOLD) (RELEASE) 










A 


l) 




B 


I 




C 


:> 


--(EXAM4,Y) 


D 
E 


i) 




F 
G 
H 



job C 




jobs C,D 


AB = R (retain job) 




NC = D (decrement job) 


job E 


AB = R (retain job) 




NC = D (decrement job) 


jobs E,l 


AB = R (retain job) 




NC = D (decrement job) 


jobs F,H 


AB = R (retain job) 




NC = D (decrement job) 


job G 


AB = R (retain job) 




NC = D (decrement job) 


none 


AB = R (retain job) 




NC = F (flush job) 


none 


AB = F (flush job) 




NC = D (decrement job) 


(EXAM4,Y) 


AB = R (retain job) 


job J 


NC = D (decrement job) 


none 


AB = R (retain job) 




NC = D (decrement job) 



How to code EXAM4: 



Jobname 


Control Statement 




(using short form of parameters) 


w 


//*NET 


ID = EXAM4,RL = (X) 


X 


//*NET 


ID = EXAM4,RL = (Y),HC=1 


Y 


//*NET 


ID = EXAM4,RL = (Z),HC = 1,AB = F 


z 


//*NET 


ID = EXAM4,HC=1,AB = F 


How to code EXAM3: 




Jobname 


Control Statements 




(using sliort form of parameters) 


A 


//*NET ID = 


= EXAM3,RL = (C) 


B 


//*NET 


ID = EXAM3,RL = (C,D) 


C 


//*NET 


ID = EXAM3,RL = (E),HC = 2 


D 


//*NET 


ID = EXAMS, RL = (E,I),HC=1 


E 


//*NET 


ID = EXAM3,RL = (F,H),HC = 2,RS = 1 


F 


//*NET 


ID = EXAMS, RL = (G),HC=1 


G 


//*NET 


ID = EXAMS,HC=1,NC = F 


H 


//*NET 


ID = EXAMS, HC=1,AB = F 


1 


//*NET 


ID = EXAMS,RL = (J),HC = 1,NR = (EXAM4,Y) 


J 


//*NET 


ID = EXAMS, HC=1 



Network Job Processing 



Network job processing (NJP) permits two or more JES3 systems to route jobs from one to the 
other using communication lines. Jobs, individually or in groups, can be scheduled for 
I processing on another system by operator or by JCL. The operator specifies what job or 
classification of jobs are to be scheduled, where the jobs are to be run, and what functions will 
be executed. For example, a job might execute on another system, but return to the original 
system for output processing. Or perhaps both execution and output processing will take place 
at the other system after beginning at the original system. Another possibiUty is that only 
output processing will be handled by the other system. 
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A group or class of jobs is identified by using the NJPCLASS parameter on the MAIN 
statement. This is a convenient method of identifying a group of jobs eligible to run on 
another JES3 system. The NJPCLASS parameter has no inherent meaning; it must be defined by 
the installation. 

When the operator tries to schedule a job for processing on a remote JES3 system, network 
job processing will determine whether the job is eligible for processing. The job may not be 
eligible if: 

• the job is already scheduled for network job processing. 

• the job is a member of dependent job control net. 

• the function to be processed has already completed. 

• the job is currently active (being processed by JES3). 

Conditional Execution of Job Steps 

Depending on the results of one step of a job, you may not wish to execute subsequent steps 
— if a compilation fails, you would not want to waste computing time attempting subsequent 
link-editing or execution steps. Specify tests to determine whether to bypass or execute job 
steps based on the results from previous steps by coding the COND parameter on the JOB or 
EXEC statements. 

The results of a job step can be reflected in a return code, a number from to 4095. The 
COND parameter can be coded to test the return codes which are issued by the compiler, 
assembler, and linkage editor programs. Some return codes are standard for certain programs; 
for example, a return code of 8 issued by a compiler or linkage editor indicates that serious 
errors were found and execution is likely to fail. In problem programs, assign a number as the 
return code to signify a certain condition. For example, if STEPl of a job reads accounts to be 
processed in subsequent job steps, set a return code of 10 if no delinquent accounts are found. 
Before STEPS is executed to process delinquent accounts, test the return code from STEPi; if 
the return code from STEPl is 10 — there are no delinquent accounts — skip STEP3. Specify 
the test to check the return code from STEPl by coding the COND parameter. 

You can also instruct the system to execute a step even if a previous step has abnormally 
terminated~br only if a previous step has abnormally terminated by coding EVEN or ONLY in 
the COND parameter on a EXEC statement. For example, STEPl of a job updates records in a 
data set. If STEPl abnormally terminates, you want to execute STEP2, which will print the data 
set. Specify that STEP2 should be executed only if STEPl abnormally terminates by coding 
ONLY in the COND parameter on the EXEC statement for STEP2. 

Note: The COND parameter is ignored when determining setup algorithms since the devices are 
assigned prior to the execution of a job. Therefore, decisions made for high watermark setup 
might not be precise because of steps that are bypassed by the COND parameter. 

Specifying Return Code Tests 

In the COND parameter, specify tests to determine if the system should bypass a job step. If 
the system determines that a comparison is true, the job step is skipped (if COND was coded 
on the EXEC statement) or all remaining job steps are skipped (if COND was coded on the job 
statement). A l^passed step has a return code of zero (0). 

For example, COND=((10,GT),(20,LT)), asks "Is 10 greater than the return code or is 20 less 
than the return code?" If the return code is 12, neither test is satisfied: no job step is skipped. 
All the tests specified must be false if processing is to continue without skipping any job steps. 
If the return code is 25, the first test is still false, but the second test is satisfied: 20 is less 
than 25. The system will bypass one job step or all remaining job steps, depending on whether 
the COND parameter was coded on the EXEC statement or on the JOB statement. 
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Passing Information to the Job in Execution 

Some information required by a program may vary from application to application, such as 
module attributes and options required by the compiler, assembler, and linkage editor 
programs. To provide this information to the program at the time it is executed, code the 
FARM parameter on the EXEC statement. The program must include instructions that can 
retrieve this information. (The exact location and format of the information passed to a 
processing program are included in OS/VS2 Supervisor Services and Macro Instructions.) 

The FARM parameter can also be coded on the EXEC statement of a cataloged or in-stream 
procedure step. This establishes fields in which information is passed to the job. Override, add, 
or nullify parameters in a procedure or define symboUc parameters by coding the FARM 
parameter on the EXEC statement of the job calling a cataloged or in-stream procedure. For 
more information on the FARM parameter for these features, see "Cataloged and In-stream 
Procedures." 

Identifying the Program to be Executed 

All executable programs are members of partitioned data sets (libraries). The library that 
contains the program can be a temporary library or a private library. In order to execute a 
program contained in these libraries, code the PGM parameter as the first parameter on the 
EXEC statement. 

Temporary Library 

To assemble, link edit, and then execute in a single job, make the output of the Unkage editor 
a member of a partitioned data set. This is accomplished by creating a temporary library; that 
is, a partitioned data set used to store a program until it is executed in a subsequent job step. 
When the program is required, refer back to the DD statement that defines the temporary 
library and the member by coding PGM=*.stepname.ddname or 

FGM=*.stepname.procstepname.ddname. Also request use of a program that is a member of a 
temporary Ubrary by coding FGM= program name and including a DD statement named JOBLIB 
or STEPLIB that defines the temporary Ubrary. To keep this program available for use by other 
jobs, make the program a member of a private Ubrary. For more information on temporary 
Ubraries, refer to the section, "Creating and Using Private and Temporary Libraries." 



Private Library 



To use a program that is a member of a private Ubrary, code FGM=program name and include 
a DD statement named JOBLIB or STEFLIB that defines the private Ubrary. The system 
automatically looks in the private Ubrary for a member with the corresponding name. 

A program that resides in a private Ubrary can also be executed by coding 
FGM=*.stepname.ddname or FGM=*.stepname.procstepname.ddname. This can be done only 
when the named DD statement defines the program as a member of a private Ubrary. For more 
information on private Ubraries refer to the section, "Creating and Using Private and 
Temporary Libraries." 



The IEFBR14 Program 



This program is used to check the syntax of the control statements, aUocate space, or satisfy 
requests for disposition processing prior to execution of a job. To do this, substitute IEFBR14 
for the program name on the EXEC statement. When this program is caUed, it gives a return 
code of and returns to the calling routine. For an example of the IEFBR14 program, see the 
example in the topic "How to Code NET Statement" in this section. 
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Testing JCL Without Execution 

There are two methods for testing JCL other than IEFBR14. The TYPRUN=SCAN parameter on 
the JOB statement and the PGM=JCLTEST on the EXEC statement both cause the system to 
scan the JCL for syntax errors without processing the job or setting up devices. Both 
parameters will check for invalid keywords, illegal characters, parentheses errors, and excessive 
parameters. 

Selecting a Cataloged Procedure Library 

You can choose which of the installation specified cataloged procedure libraries will be used 
for resolving catalog procedure references in the JCL by coding the PROC parameter on the 
MAIN statement. If this parameter is omitted, the installation standard library, denoted by ST, 
will be used. 

If you want to update a cataloged procedure library, whether or not that library was used to 
resolve the job's library references, code the UPDATE parameter on the MAIN statement 
pointing to the library to be updated by that job. JES3 will effectively disable the use of that 
library, placing all jobs that request it into a held state until the updating job terminates. This 
prevents the use of the library while the update occurs. 

Reading Column Binary Input 

Jobs that require input from column binary cards can receive this input directly from the DD 
statement if JES3 is used by coding the MODE=C DCB subparameter on the DD * or DD DATA 
statement that precedes the column binary card input and by notifying the operator to read 
this job into a card reader for which he has specified mode C processing. 

The DATASET statement can also be used to read column binary input for jobs to be run on 
ASP main processors only and for installation-written routines executed as part of nonstandard 
I jobs. See the section, "The PROCESS Statement" for a discussion of nonstandard jobs. 

Restarting a Job 

When a job step abnormally terminates, you may have to resubmit the job for execution; this 
means delay and lost computer time. The operating system provides restart facilities to reduce 
the effects of abnormal termination. 

There are three types of restarts: 

• Step restart, from the beginning of a job step. 

• Checkpoint restart, from a checkpoint within a job step. Establish checkpoints in a job step 
by coding the CHKPT macro instruction for each checkpoint. The CHKPT macro is described 
in OS/VS Data Management Macro Instructions. See also the DD CHKPT parameter. It specifies 
that checkpoints are to be taken at end of volume for the data set defined by the DD 
statement on which it is coded. 

• System failure restart, by specifying the FAILURE = RESTART parameter on the JES3 MAIN 
statement. In the event the job cannot complete executing because of system failure, JES3 
will automatically reschedule the job from the beginning. Other options on the FAILURE 
parameter are CANCEL, HOLD, and PRINT. All of the values are described on the MAIN 
FAILURE parameter in the section, "Coding JES3 Statements." 

Whether using step restart or checkpoint restart, the restart facility can be automatic or 
deferred. 
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Automatic restart: To use automatic restart, code the RD (restart definition) parameter on the 
JOB or EXEC statement. JES3 creates a job journal for any job specif5dng the RD parameter. (A 
job journal is established to hold restart information for each program in execution.) When a 
system failure occurs or a job step abnormally terminates and you have a job journal, the 
restart facility allows automatic restart when RD=R is coded on the JOB or EXEC statements. If 
checkpoints are taken, you can automatically restart at the last checkpoint regardless of 
whether or not the RD parameter is coded. When a job step abnormally terminates or a system 
failure occurs while the job is in execution and the installation has not implemented job 
joumaling, these jobs are ineUgible for automatic restart. 

Deferred restart: To use deferred restart, code the RESTART parameter on the JOB statement. 
This required parameter specifies a job step or a step of a cataloged procedure and can specify 
a checkpoint identifier if you are using deferred checkpoint restart. The effect of the parameter 
is simply to restart the job at the beginning of the specified step or checkpoint. The SYSCHK 
DD statement is required when a job is being submitted for deferred checkpoint restart and 
must be placed immediately after a JOBLIB DD statement. 

Jobs mnnii^ on ASP Main Processors: The MAIN JOBSTEP parameter specifies the job step 
checkpoint option for jobs on ASP main processors only. The checkpoint option will not be 
taken if JOBSTEP=NOCHKPNT is coded or if nothing is coded; the checkpoint will be taken at 
the end of each job step if JOBSTEP=CHKPNT is coded. If a checkpoint is requested, it means 
that the ASP user can see the output up through the last completely executed step if the system 
crashes and the job is not restarted. Otherwise, there is no job produced output. The MAIN 
JOBSTEP parameter is ignored in MVS; the job step checkpoint feature is standard. 

Refer to OS/VS Checkpoint/Restart for a complete description of planning for and using the 
checkpoint restart facility. 

Example of Routing a Job Through the System (JES3 only) 

//EXAM JOB 

//*MAIN SYSTEM=(MAIN1 ,MAIN2),SETUP=(DD1 ,DD2), 

//*FAILURE=RESTART 

//STEP1 EXEC PGM=IEFBR14 

//DD1 DD UNIT=3330,VOL=SER=VOL1 ,DISP=OLD, 

// DSN=JES3.EXAM 

//STEP2 EXEC PGM=IEFBR14 

//DD2 DD UNIT=3330,SPACE=(TRK, 1 ),V0L=SER=V0L2 

1. This job is assigned to an installation defined job class default. 

2. The selection for processing is based on the priority assigned to the default class. 

3. The MAIN statement specifies that this job can be processed on either MAINl or MAIN2. 
The job requires that the volumes associated with the DDl and DD2 statements must be 
mounted. 
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Obtaining Output (JES3 only) 



You can request output by coding JCL and JES3 control statements. By coding JCL statements, 
you can request output data sets, listings of JCL statements, system messages, and abnormal 
termination dumps. By coding JCL and JESS statements, you can request special forms 
processing, routing of output to specific devices, and multiple original printing by data sets 
within a job. The JES3 statements have the same options as JCL with some additional features 
such as the FORMAT statement forms overflow, forms control, and multiple data set 
characteristics. 

This section includes five topics: 

• Requesting Listings of JCL Statements and System Messages 

• Requesting an Abnormal Termination Dump 

• Writing Output Data Sets 

• Controlling Output Destination 

• Remote Job Processing 

Requesting Listings of JCL Statements and System Messages 

The system produces messages about a job concerning allocation of units and volumes, 
disposition of data sets, and termination of job steps and the job. Request that these messages 
and/or the JCL statements from the job and from cataloged procedures called by the job be 
included on an output Usting. 

By coding the MSGLEVEL parameter on the JOB statement, you inform the system of what 
statements and messages you want included on the output Listing. (The notation used on the 
output listing to identify cataloged and in-stream procedure statements is described in the 
chapter "Using Cataloged and In-stream Procedures.") 

By coding the MSGCLASS parameter on the JOB statement, you assign messages and JCL 
statements to an output class. A default is assigned if MSGCLASS is not coded. 

The JES3 FORMAT statement allows you to specify the ddname of the DD statement that 
defines the output data set characteristics you want to specify. If you want system messages, 
code DDNAME=SYSMSG; if you want the jclfile including statement messages, code 
DDNAME=JESJCL; or if you want JES3 and system operator messages (job log), code 

DDNAME=JESMSG. 

Requesting an Abnormal Termination Dump 

To obtain a dump in the event of abnormal termination of a job step, code a DD statement 
defining a dump data set. The name of the DD statement must be either SYSABEND or 
SYSUDUMP. If both DD Statements are present, the first one is used. 

The SYSABEND or SYSUDUMP DD Statements can provide a dump containing the processing 
program's virtual storage area, the system nucleus, the entire system queue area, all local 
system queue areas, and any active link pack area (lpa) modules for the faihng task. If the 
generalized trace faciUty (gtf) is active in the system and performing an internal trace, you 
receive GTF trace records. If GTF is active but performing an external trace, no trace 
information is included in the dump. Determine what dump features are wanted in addition to 
the installation defaults and define them in a dump option Ust. How to do this is explained in 
the OS/VS2 System Programming Library: Supervisor. 
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Dumps with more data per page are available with the 3800 Printing Subsystem. By 
specifying CHARS=DUMP on the related DD statement, the dump is formatted in a 
204-character line containing 64 bytes of storage. If FCB=STD3 is specified, the page is printed 
at 8 lines per inch. The dump program recognizes only STD3 for producing 8 lines per inch. 
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Descriptions of dumps and information on reading dumps are included in the OS/VS2 System 
Programming Library: Debugging Handbook. 

To have the dump printed, either assign the dump to an output class in the SYSOUT 
parameter on the DD statement or code the UNIT parameter and specify the printer you want. 
To store the dump, define the data set as you would any other data set, coding the DSNAME, 
DISP, UNIT, and VOLUME parameters. If the data set wUl go to a direct access device, code the 
SPACE parameter. 

If a private data set is specified and more than one dump is possible, the data set should be 
specified with a disposition of MOD as it will be closed after each dump. 

Writing Output Data Sets 

There are two ways to write output data sets: 

• Assign the data set to an output class. 

• Specify the device on which the output should be written. 

When you assign a data set to an output class, it is handled by JES3. The data set is first 
written to the JES3 spool device and then written to the final output device by either JESS or 
an external writer. When you specify the device on the UNIT parameter, if the device is 
available, it is exclusively assigned to your job and under the control of your program. 

Assigning Output Data Sets to Output Classes 

Output classes include output with similar characteristics that are written to the same device. 

There are 36 possible output classes, defined by an alphabetic (A-Z) or numeric (0-9) 

character, that can be coded on either the SYSOUT or MSGCLASS parameters. The letter and ■ 

number names have no inherent meaning; — each installation defines its own output classes ~ 

and can assign special processing characteristics for each class. For example, output class W 

might contain low priority output; class X might contain output to be printed on a special form 

(eliminating the need to request the form directly); class J might be reserved for high- volume 

output. If you want the output data set and messages from the job to be printed on the same 

output listing, specify SYSOUT=* or the same output class in the SYSOUT parameter as 

specified for messages in the MSGCLASS parameter. 

The installation can designate certain SYSOUT data sets as reserved. Reserved classes can 
cause the data sets to be held; that is, not sent to JES3 output processing. If the output class 
specified for the MSGCLASS parameter is not designated as a reserved class, it will not be held 
and none of the job's data sets assigned to reserved classes will be held. Data sets can be 
explicitly held by coding the HOLD = YES parameter or by coding TSO commands. (Refer to 
OS/VS2 TSO Command Language Reference for information on the TSO commands.) Jobs are 
released from the hold state for the entire job by the operator or by the time-sharing user, 
with the OUTPUT TSO command. By using reserved classes, the controlling of the holding or 
not holding of all desired print data sets is done by means of the MSGCLASS parameter on the 
JOB statement. 

. Specifying the Device 

To write an output data set without using JES3 output service, code the UNIT parameter on the 

DD statement defining the device on which the data set is written. Tlie system wiU allocate the 

device exclusively to the job if the device is available; no other job can write output to that 

device until it is released. Jobs cannot share an output device as they can when the output is 

assigned to output classes. d 
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Data management routines write the output from the program to the device specified in the 
UNIT parameter. Specifying a particular output device in the UNIT parameter generally is not 
the most efficient method for obtaining system output. 



Processing Output Classes 

Using JES3 is an efficient way to write output. JES3 supports the use of local and remote 
printers and punches as devices on which output classes are written. An external writer 
supports tape and direct access devices and user-written writer routines. 

Output will be printed on the same listing if such parameters as CLASS, FORMS, FCB, UCS, 
and DEST have similar characteristics for all data sets and a user-written writer is not specified. 

For an external writer, the operator will determine what data sets will be selected. When an 
external writer is specified, an iBM-suppUed writer or a user-written writer will receive the 
output. The external writer must be started by the operator to have the data written to an 
output device. If you want to know more about how to write an external writer routine, refer 
to OS/VS2 System Programming Library: Job Management. 

Output data sets to be written to a 3540 diskette must be assigned to an output class that is 
processed by the diskette writer (an external writer) as described in OS/VS2 IBM 3540 
Programmer's Reference. For the diskette writer to receive data sets, the JES3 initialization deck 
must specify the SYSOUT classes to be reserved for diskette output. To write data sets on a 
diskette, the operator must start the diskette writer to a 3540 device. 

Delaying the Writing of an Output Data Set 

Data sets can be delayed from normal printing or delayed for inspection from a time sharing 
terminal prior to actually printing on that terminal by specifying reserved classes (as discussed 
next) and by coding the HOLD parameter. For example, the installation can direct the delayed 
printing of a very large data set to prevent monopolizing an output device untU smaller data 
sets are written. If a data set requires special forms that are not immediately available, it can 
be held until the operator supplies those forms. When HOLD=YES is specified on the DD 
statement, the data set is placed on a hold queue until the operator releases it. Notify the 
operator (using the OPERATOR statement for JES3) when that data set is ready for processing 
because no message will be sent to the operator. The data set must be released by the operator 
or time-sharing user for printing. 



Suppressing the Writing of an Output Data Set 



Whether writing an output data set by coding the SYSOUT parameter or the UNIT parameter, 
you can suppress the writing of the data set by defining it as a dummy data set. This is useful 
when testing a program and you do not want data sets printed until you are sure they will 
contain meaningful output. Suppressing the writing of a data set saves processing time. 

If you are routing an output data set by coding the SYSOUT parameter, code the DUMMY 
parameter to define the data set as a dummy data set. When DUMMY is coded, the SYSOUT 
parameter is ignored and the data set is not written. 

You can suppress the writing of an output data set by specifying particular 
installation-defined class defined to delete the data set before it is printed. This technique is 
used by the installation to suppress the output of started tasks such as START and MOUNT 
commands. You can also suppress the writing of an output data set by specifying COPIES=0 on 
the FORMAT PR or PU (print or punch) statements. 
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If the device on which the data set will be written is specified in the UNIT parameter, you 
can assign the data set a dummy status by coding DUMMY or by assigning the data set name 
NULLFILE. All parameters other than DUMMY or DSNAME=NULLFILE and DCB are ignored; 
ho units are assigned to the data set. When the program requests that the data set be written, 
the request is recognized but no data is transmitted. The facility is available by use of the basic 
sequential access method (BSAM) or queued sequential access method (QSAM) in a request to 
write a dummy data set. If any other access method is used, the job is terminated. 



Limiting Output Records 

The number of logical records in the output data set can be limited by specifying a maximum 
number of records through the use of the OUTLIM parameter on the DD statement; For 
example, a program is printing and goes into an endless loop. You anticipate the problem and 
have a maximum number of records printed before the system discontinues the output 
processing. 

To limit the printed or punched output of a job, specify the estimated number of lines of 
output or the estimated number of cards associated with your job's output by coding the LINES 
and CARDS parameters on the MAIN statement. This information is used by JES3 to monitor 
output and take whatever action is specified if you exceed the estimates. These actions request 
that the operator receive a warning (the WARNING subparameter), that the job is canceled 
(the CANCEL subparameter), or that the job is canceled with a storage dump (the DUMP 
subparameter). JES3 initialization parameter values are used if you omit the estimates. 

The LINES parameter will not limit the size of an internal reader data set because it is not 
considered to be part of the printed output of a job. To restrict this type of data set, the 
OUTLIM parameter must be specified on the DD statement. 

Requesting Multiple Copies of an Output Data Set 

You can control the number of hard copies produced by the SYSOUT data sets. You can 
request as many as 254 copies of an output data set by coding the COPIES parameter on the 
SYSOUT DD statement defining the data set or up to 255 copies by coding the COPIES 
parameter on the JES3 FORMAT PR control statement. 

With the 3800 Printing Subsystem, you can also specify on the SYSOUT DD statement or on 
the FORMAT PR statement how the copies of the output data set are to be grouped. Each 
group value of the COPIES parameter specifies the number of copies of each individual page 
that is to be printed before copies of the next page are printed. The total number of copies 
printed equals the sum total of the group values. 

Requesting Copy Modification 

Selected copies of output can be modified when using the 3800 Printing Subsystem by 
specifying a copy modification module name on the MODIFY parameter of the SYSOUT or 
output DD statement or on the JES3 FORMAT PR statement. This allows the printing of 
predefined data on all pages of a specific copy or copies of a data set. For example, you may 
want to vary column headings or explanatory remarks on different copies of the same printed 
page of data. Copies might also be personalized with the recipient's name, address, and other 
desired information. Blanks or printable characters, such as asterisks, might also be used to 
suppress the printing of variable data on particular copies of a page. (This is a function done 
in other printers by using short or spot carbon in the forms set.) 

The predefined data is created as a copy modification module and stored on SYSI.IMAGELIB 
using the lEBIMAGE utility program. For information on using lEBIMAGE, see the IBM 3800 
Printing Subsystem Programmer's Guide. 
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I Requesting Printer Form and Character Control 



When requesting that an output data set be written, you can give JES3 special instructions on 
how to write the data set. You can request: 

• A special output form. 

• A special character set or arrangement, when output is being printed by a 3211 or 1403 
printer with the universal character set feature or by a 3800 Printing Subsystem. 

• A specific FCB (forms control buffer) module, which controls how many hnes per inch are 
printed and the length of the form, when the data set is written to a 3211 printer or a 3800 
Printing Subsystem. 

• A specific carriage control tape, when the data set is written to a 1403 printer. 

• A test for printer overflow and spacing. 

• Interpretation of punch output on the 3525. 
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Requesting a Special Output Form 

Special forms are requested for output data set printing by including the form name in the 
SYSOUT parameter on the DD statement defining the data set or by coding the FORMS 
parameter on the FORMAT PR control statement. For example, assign a data set to an output 
class to be routed to a printer and specify the data set be printed on a special form. (For 
example, code SYSOUT=(A„FMS2).) JES3 and the external writer insure that the proper form is 
mounted. 

Requesting a Special Character Set Using the UCS Feature 

The universal character set (UCS) feature is requested by coding the UCS parameter on a DD 
statement defining an output or SYSOUT data set or by coding the TRAIN parameter on the 
FORMAT PR control statement for SYSOUT data sets. You can request the UCS feature for 
different sets of characters to be printed for various applications. 

To request a special character set for a 3211 or 1403 printer, specify the code identifying 
the character set in the UCS parameter or the FORMAT statement. The codes for the IBM 
standard special character sets are in Figure 12. 



1403 


3211 


Characteristics 


AN 
HN 
GN 
PCAN 

PCHN 

PN 
QN 
QNC 

RN 

SN 

TN 
XN 

YN 


All 
Hll 
Gil 

Pll 
Til 


Arrangement A, standard EBCDIC character set, 48 characters 

Arrangement H, EBCDIC character set for FORTRAN and COBOL, 48 characters 

ASCII character set 

Preferred alphameric character set, arrangement A 

Preferred alphameric character set, arrangement H 

PL/1 alphameric character set 

PL/1 preferred alphameric character set for scientific applications 

PL/1 preferred alphameric character set for commercial applications 

Preferred character set for commercial applications of FORTRAN and COBOL 

Preferred character set for text printing 

Character set for text printing, 120 characters 

High-speed alphameric character set for 1403, Model 2 

High-speed preferred alphameric character set for 1403, Model 3 or Nl 



Figure 12. Special Character Sets for the 1403 and 3211 Printers (JES3) 

Note: Where two values exist (for the 1403 or 3211 printers), either can be coded and.JES3 
selects the set corresponding to the device on which the data set is printed. 

Not all of these character sets may be available at your installation. In addition, the 
installation can design character sets to meet special needs and assign a unique code to them. 
See the system programming staff for a complete Ust of available character sets for the 
installation. 

Requestii^ Character Arrangements with a 3800 Printing Subsystem 

Character arrangement tables to be used when printing with the 3800 are specified with the 
CHARS param^eter on the SYSOUT or output DD statement or on the JES3 FORMAT PR 
statement. The table names supplied for the 3800 are given in Figure 28 A. See your system 
programmer for the selection of table names available at your installation. 

When more than one character arrangement table is specified, you can code OPTCD=J as a 
DCB subparameter to indicate^that your data line contains a table reference character for 
dynamically selecting the table you want. (See the description of the OPTCD subparameter for 
BSAM and QSAM in the topic, "The DCB Parameter".) Using the lEBlMAGE utility program, 
you can modify or construct character arrangement tables and graphic character modification 
modules to allow substitution of existing or user-designed characters. Details for using both 
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lEBIMAGE and the OPTCD subparameter are provided in the IBM 3800 Printing Subsystem 
Programmer's Guide. 

The UCS (universal character set) parameter can be specified on the same output DD 
statement with the CHARS parameter to permit output to go to either the 3800 or to other 
printers. The GFIO, GF12, or GF15 character arrangement table coded on the chars parameter 
provides the same effect as the FOLD subparameter of UCS. If a printer other than the 3800 is 
allocated, the CHARS parameter is ignored. 



( 



Requesting Forms Control 



For a 1403 Printer: Forms control is requested by specifying a specific carriage control tape in 
the CARRIAGE parameter on the FORMAT PR control statement. Carriage specifications are 
used for JES3 output processing only; they are ignored by the external writer. 

For a 3211 Printer: Specific forms control images (for example, the number of lines per page 
or number of characters per line) are requested by coding an image identifier in the FCB 
parameter on a DD statement or on the FORMAT PR control statement. A carriage control tape 
for JESS output processing only can also be specified in the CARRIAGE parameter on the 
FORMAT PR control statement. The FCB image is stored on SYSI.IMAGELIB. IBM provides two 
standard FCB images: STDl and STD2. STDl specifies that 6 Unes per inch are to be printed on 
an 11 -inch form. STD2 specifies that 8 lines per inch are to be printed on an 8. 5 -inch form. 
(Do not specify STDl or STD2 for JESS processing unless instructed by your installation.) 
Additional FCB images can be specified by the installation. For information on IBM- and 
user-supplied FCB images, see OS/VS2 System Programming Library: Data Management. 

For a 3800 Printing Subsystem: Forms control is requested by specifying an FCB module name 
in the FCB parameter on a DD statement or on the FORMAT PR control statement. (Although 
the FCB image for the 3211 and the FCB module for the 3800 serve the same purpose, they 
are constructed differently and are not interchangeable between the two printers.) The FCB 
module is stored on SYSI.IMAGELIB. IBM provides a standard FCB module, STD3, which 
specifies output of 80 Unes per page at 8 lines per inch on 11 -inch long paper. (For a 3800 
using ISO paper sizes, STD3 can be redefined by the installation.) Additional FCB modules can 
be specified by the installation. For information on IBM- and user-supplied FCB modules, see 
the IBM 3800 Printing Subsystem Programmer's Guide. 



i 
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Requesting Forms Overflow and Printer Spacing 

You can prevent the printing of a data set across the folds in the forms by coding the OVFL 
parameter on the JES3 FORMAT PR statement. (This does not apply to the 3800 Printing 
Subsystem, which cannot print across the folds.) An example of this is having many SYSMSG 
data sets that have been printed one after another. 

The FORMAT CONTROL parameter specifies the type of forms control used. You can force 
single or double spacing or indicate that the carriage control character is the first character of 
each logical record in the data set. You might force single spacing, for example, when testing 
the first character of each logical record to see if all the characters indicate the spacing 
required on an actual run. By coding the PROGRAM parameter, you are specifying that you 
want to use the DCB RECFM value. OVFL should not be specified when PROGRAM is used. 

Requesting Punch Output Interpretation on a 3525 

Punched output may or may not be interpreted depending on the installation-defined standard 
for the SYSOUT class. You can specify punched output to be interpreted by coding the 
INT=YES parameter on the JES3 FORMAT PU statement. If you omit the device name that 
specifies a 35251, JESS attempts to find one for the output. If you specify a non-interpreting 
punch device, output is punched on it but not interpreted. 

Cards punched on a 3525 card punch from output spooled by JESS will be interpreted if you 
code FUNC=I as a DCB subparameter on the SYSOUT card and if the spooled output is 
processed by a JESS writer rather than the external writer. The FUNC=I subparameter will be 
ignored if the spooled output is processed by the JESS writer onto a card punch other than the 
3525. You should check with the installation to determine if a special output class has been set 
aside for 3525 output.- Card interpretation by the external writer is an operator specified 
function. Output to be interpreted should be placed in a class designated by the installation as 
a punch with interpretation class. 

Requesting Forms Overlay 

The forms overlay feature of the 3800 Printing Subsystem allows printing of the image from a 
forms overlay negative together with the data being printed. This reduces the need for 
pre-printed forms, and for changing of forms. The FLASH parameter on the DD statement or 
on the JESS FORMAT PR Statement identifies the overlay to be used and the number of copies 
on which that overlay is to be printed. For information on designing and making or obtaining 
forms overlay negatives, see the Forms Design Reference Guide for the IBM 3800 Printing 
Subsystem. 

Bursting of Output 

The optional Burster-Trimmer-Stacker of the 3800 Printing Subsystem separates continuous 
form paper into individual sheets. The BURST parameter on the DD statement or the STACKER 
parameter on the JESS FORMAT PR statement is used to specify to the operator whether the 
output is to go to the Burster-Trimmer-Stacker or to the continuous forms stacker. For further 
information and examples, see the topic, "The BURST Parameter". 

Controlling Output Destination 

JESS allows you to submit jobs to a central computing center from a work station and to route 
output (submitted anywhere) to work stations. 

When submitting a job from a local CPU or a work station, the output is returned to the i 

place where it is submitted unless you code ORG or you specifically route the output; simply 
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assign output data sets to an output class (with the SYSOUT parameter) and messages from the 
job to an output class (with the MSGCLASS parameter). At remote stations, JES3 offers most of 
the same options for writing data sets that are requested when submitting the job at the central 
computing center. You can request: 

• That a data set be held until the operator requests that it be printed. 

• That a special output form be used by specifying a form name in the SYSOUT parameter. 

• That multiple copies of the data set be used. 

Whether at a remote station or at the central computing center, you can also request that a 
data set be routed to another destination. To route an output data set to another destination, 
code the identification of that destination in the DEST parameter on the DD statement defining 
the data set, code the MAIN ORG statement, or code the FORMAT PR or PU DEST parameters. 
Work stations are identified by a destination identification that has been established by the 
system programmer. The DEST parameter on the DD statement and the DEST parameter on the 
FORMAT PR and PU statements route individual data sets to a remote destination (work 
station), a local destination (central computing center), or a specific local device. In addition, 
the USER, MAIN, and HOLD parameters on the FORMAT AC statement and/or the USER, 
ACMAIN, and ACHOLD parameters on the MAIN statement may be used to control the 
disposition and routing of output data sets to ASP main processors for use by TSO users. For 
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more information on TSO support on ASP main processors, see the next section and the 
discussions of the FORMAT AC and MAIN statements. 

TSO On An ASP Main Processor 

TSO users on an ASP main processor who want to use special FORMAT AC options or retrieve 
data from other than an AC class and users who want to route data sets to TSO users on an 
ASP main processor must code the FORMAT AC statement. This statement defines output to be 
accessed, output destination, and other parameters concerning output handUng. If the data set 
is processed at any time by the ASP main processor, regardless of where the job is processed, 
you must code the FORMAT AC statement. 

Remote Job Processing 

Jobs can be submitted to JES3 for processing from remote binary synchronous work stations 
using remote job processing (RJP). Any job submitted from a remote work station will, by 
default, have its output (print and punch) returned to the originating work station unless JES3 
has been instructed to do otherwise using FORMAT or MAIN ORG statements. The remote user 
has almost all the capabilities of the local JES3 user with the restriction that column binary 
input and output can not be used. In addition, you can not uniquely specify printer overflow 
specifications. 

Routing output to other destinations is also possible using the DEST parameter on the 
I FORMAT statement and the DD statement. Refer to the previous section for more information. 

Example of Obtaining Output (JES3 only) 

This example shows the use of JES3 and JCL statements that can be used to obtain output. 

//OUTJOB JOB BAKER,PERFORM=100,MSGCLASS=J 
//♦FORMAT PR , DDNAME= , C0PIES=2 , FORMS=GRN 1 
//*FORMAT PR , DDNAME=DD3 , DEST=PRINTER8 , CARRIAGE=STD3 , 
//*F0RMS=2PRT , TRAIN=TN 

PGM=TESTSYSO 

DSN=DATA, UNIT=23 1 4 , VOL=SER=SCHLIB , 

DISP=(OLD,KEEP),SPACE=(TRK,(5,2 ) ) 

DSN= STEMP , UNIT=2 3 1 4 , DISP=( NEW , DELETE ) , 

SPACE=(TRK,( 10,5) 

SYSOUT=(A) 

SYSOUT=(A, ,GRPH) 

SYSOUT=L 

1. The job will run in performance group 100; the meaning of 100 is defined by the 
installation. All system messages are to be written to output class J. 

2. The first FORMAT statement indicates that: 

a. All print data sets (according to class) with no FORMAT statements will be printed 
according to the parameters on this statement unless the output class defines specific 
processing characteristics (DDNAME is coded without a name). 

b. Two copies are printed. 

c. Forms name GRNi and two copies are to be used by all data sets unless a specific 
form or number of copies is defined on a DD statement or by class by the installation. 



//STEP1 


EXEC 


//DD1 


DD 


// 




//DD2 


DD 


// 




//DD3 


DD 


//DD4 


DD 


//DD5 


DD 
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3. The second FORMAT statement indicates that: J 

a. The destination for the output is a printer that has an installation-defined name of 
PRINTERS. 

b. If PRINTERS has the forms control buffer feature, STD3 must be the name of a 
member of SYSI.IMAGELIB. STD3 defines the special forms control buffer image or 
carriage tape to be used for processing the job. 

c. Forms name 2PRT is the name of the forms for DD3. 

d. TN means text printing on a 1403 printer. 



c 



I 
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Special Data Sets 



Data sets can be defined to satisfy a special purpose. Such data sets are usually defined with a 
special ddname, a specific data set name, or a specific parameter. 

This section includes seven topics: 

Creating and Using Private and Temporary Libraries 

Defining a Dummy Data Set 

Using Virtual Input/Output (VIO) for Temporary Data Sets 

Entering Data Through the Input Stream 

VSAM Data Sets 

Creating and Retrieving Indexed Sequential Data Sets 

Creating and Retrieving Generation Data Groups 

Creating and Using Private and Temponffy Libraries 

A library is simply a partitioned data set — a data set in direct access storage that is divided 
into partitions, called members, each of which can contain a program or part of a program. 
Each partitioned data set contains a directory (or index) that the control program can use to 
locate a program in the library. All programs that can be executed must exist in a library; that 
is, they must be members of a partitioned data set. 

A private Ubrary is a partitioned data set that contains user-written programs. You inform 
the system that a program exists in a private library by coding a DD statement defining that 
library. You can define a private library to be used throughout the job by coding a DD 
statement with the ddname JOBLIB, or define a Ubrary to be used in a specific step by coding a 
DD statement with the ddname STEPLIB. 

A temporary library is a partitioned data set created in the job to store a program, as a 
member of the partitioned data set, until it is executed in a following step. For example, :f in 
the job you want to assemble, hnkage edit, and then execute a program, make the output of 
the Unkage editor a member of a Ubrary. Any Ubrary that created and deleted in the same job 
is a temporary Ubrary. 

Code the PGM parameter as the first parameter on the EXEC statement to execute a 
program contained in a Ubrary. If the program exists in a private library, code PGM = program 
name and either a JOBLIB or STEPLIB DD statement. If the program exists in a temporary 
library, code either PGM=*.stepname.ddname or PGM=*.stepname.procstepname.ddname. 
Ddname is a temporary Ubrary created in and pointed to by stepname and procstepname. They 
identify the job step or job step and procedure step defining the Ubrary. If you define a private 
library, the system looks in that Ubrary for the program you want executed. 

This chapter describes how to code JCL statements to create or retrieve private and 
temporary Ubraries. Complete information on creating a partitioned data set, adding members 
to and deleting members from a partitioned data set, is included in OS/VS Data Management 
Services Guide. 

Creating a Private Library 

Use the JOBLIB DD statement to create a private library. The JOBLIB DD statement must 
appear immediately after the JOB statement — do not use the ddname JOBLIB unless you are 
defining a private Ubrary. The Ubrary defined with a JOBLIB DD statement is automaticaUy 
available to every step in the job. (The STEPLIB DD statement is included among the DD 
statements in a step and is avaUable only to that step unless you pass the library or redefine it 
in subsequent steps; since the Ubrary on a JOBLIB DD statement is available to every step, it is 
easier to create a Ubrary with the JOBLIB DD statement.) 
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When creating the library on the JOBLIB DD statement, you are creating a partitioned data 
set. Steps in the job must add members to the library before those members (programs) can be 
used by subsequent steps. 

On the JOBLIB DD statement, assign the library a name in the DSNAME parameter, give unit 
and volume information in the UNIT and VOLUME parameters (a partitioned data set must be 
contained on one direct access volume; if, however, you make a nonspecific volume request, 
you need not code the VOLUME parameter), request space for the entire library in the SPACE 
parameter, and assign a data set status and disposition in the DISP parameter. Code NEW as 
the data set status and either CATLG or PASS as the data set disposition. When specifying 
CATLG, the library is cataloged, available throughout the job, and kept at the end of the job. 
When specifying PASS, the library is available throughout the job, but is deleted at job 
termination. (If you do not code a disposition, or code a disposition other than CATLG or 
PASS, the system assumes PASS.) You must also code the DCB parameter if complete data 
control block information is not included in the data set label. 

Adding Members to a Private Library 

Add members to the library in job steps within the job by coding a DD statement that defines 
the Ubrary and names the member to be added to the library. In the DSNAME parameter, 
follow the library name with the name of the program being added to the library, for example, 
DSNAME=LIBRARY(PR0GRAM). Do not code the SPACE parameter; request space for the 
entire library on the JOBLIB DD statement. In the DISP parameter, specify MOD as the data set 
status; the partitioned data set already exists since you created it in the JOBLIB statement, and 
you are lengthening it with a new member. If you cataloged the library in the JOBLIB DD 
statement, that is, coded DISP=(NEW,CATLG), do not respecify CATLG when adding a 
I member: you need not code a second disposition at all. For a cataloged library, you do not 
have to specify unit and volume information, except in one instance: if you are adding a 
member to the library in the first step of the job, supply unit and volume information; the 
library is not cataloged until the first step completes the execution. Refer to the JOBLIB DD 
statement for unit and volume information by coding VOL=REF=*.JOBLlB. 

In the following example, the JOBLIB DD statement creates a library named GROUPLIB; 
STEPl adds the program RATE to the library; STEP2 calls the program RATE: 

//EG JOB MSGLEVEL=1 

//JOBLIB DD DSNAME=GROUPLIB,DISP=( NEW, CATLG), 
// UNIT=2314,VOL=SER=727104, 

// SPACE={CYL,( 50,3,4) ) 

, //STEPl EXEC PGM=FIND 

//ADDPGMD DD DSNAME=GROUPLIB( RATE ) , DISP=MOD, 
// VOL=REF=*. JOBLIB 

//STEP2 EXEC PGM=RATE 

In STEPl, the system looks for the program named FIND in SYSI.LINKLIB — the private 
library created on the JOBLIB DD statement does not actually exist until a member is added to 
it. In STEP2, the system looks for the program named RATE first in the private library. 

Retrieving an Existing Private Library 

If you are retrieving several programs from one library (several steps in the job will be using 
the library), use the JOBLIB DD statement to define the library: the library will be available in 
every step of the job for which you do not code a STEPLIB DD statement. The JOBLIB DD 
statement must appear immediately after the JOB statement. To make a library available in a 
single step, define the library on a STEPLIB DD statement. The STEPLIB DD statement is 
included with the DD statements for a step (in no specific order) and is available only to that 
step, unless you pass the library and retrieve it in a subsequent step. Use the ddnames JOBLIB 
and STEPLIB only when defining private libraries. 
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The system will search for a program in the private library you define. If both JOBLIB and 
STEPLIB DD statements appear in a job, the STEPLIB definition has precedence, that is, the 
private library defined by the JOBLIB DD statement is not searched for any step that contains 
the STEPLIB definition. If you want JOBLIB definition ignored but the step does not require use 
of another private library, define a system library on the STEPLIB DD statement: 

//STEPLIB DD DSNAME=SYS1 .LINKLIB,DISP=SHR 

Retrieve a private Ubrary as you would any partitioned data set: if the Ubrary is cataloged, 
or in the case of a STEPLIB definition, passed from a previous step, you need not specify unit 
and volume information; otherwise, you must code the UNIT and VOLUME parameters. 

For both cataloged and uncataloged Ubraries, code: the DSNAME parameter, specif ymg the 
name of the Ubrary; the DCB parameter, if complete data control block information is not 
included in the data set label; and the DISP parameter, specifying data set status and 
disposition. Normally, you will want to specify SHR as the data set status: SHR indicates that 
the data set is old, but also allows other jobs to simultaneously use the Ubrary. AU references 
to the library in the job must specify SHR if the data set is to be shared; do not code SHR, 
however, if you wiU be adding members to the Ubrary in the job. (A more thorough discussion 
of sharing a data set is included in the chapter "Insuring Data Set Integrity.") Code PASS as 
the data set disposition for a Ubrary defined on the JOBLIB DD statement: PASS makes the 
Ubrary available throughout the job. (If you do not code a disposition, the system assumes 
PASS.) For a library defined on a STEPLIB DD statement, code any vaUd disposition, depending 
on how you want the data set treated after its use in the job step: for example, if the Ubrary is 
not cataloged, and you want it to be cataloged, code CATLG; if you want the library deleted, 
code DELETE. 

The foUowing job includes both JOBLIB DD and STEPLIB DD statements: 



//CAMILLE 


JOB 


MSGLEVEL='I 


//JOBLIB 


DD 


DSNAME=LIB5 . GRP4 , DISP=SHR 


//STEP1 


EXEC 


PGM=FIND 


//STEP2 


EXEC 


PGM=GATHER 


//STEPLIB 


DD 


DSNAME=ACCOUNTS , DISP=( SHR , KEEP ) , 


// 




UNIT=23 1 4 , VOL=SER=727 1 04 



In STEPl, the system searches the Ubrary named LIB5.GRP4, defined on the JOBLIB DD 
statement, for the program named FIND. In STEP2, the system searches the Ubrary named 
ACCOUNTS, defined on the STEPLIB DD statement, for the program named GATHER. 

Add a program to an existing Ubrary by coding a DD statement in a job step that defines 
the Ubrary and names the program to be added — see "Adding Members to a Private Library" 
for details on coding this DD statement. The new member must be added to the Ubrary before 
it can be executed (the step that adds the program to the Ubrary must precede the step that 
caUs the program). Do not code SHR as the data set's status when modifying the Ubrary. 



Concatenating Private Libraries 



If the job uses programs contained in several Ubraries, you can concatenate these Ubraries on 
one JOBLIB DD statement or one STEPLIB DD statement; aU the Ubraries concatenated must be 
existing Ubraries. Omit the ddname from aU the DD statements defining the libraries, except 
the first: 

DSNAME=D58.LIB12,DISP=( SHR, PASS ) 
DSNAME=D90 . BROWN, DISP={ SHR, PASS ) , 
UNIT=3330,VOL=SER=41 1731 
DSNAME=A03 . EDUC, DISP=( SHR, PASS ) 



//JOBLIB 


DD 


// 


DD 


// 




// 


DD 
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This entire group must appear immediately after the JOB statement. When concatenating 
libraries using STEPLIB as the ddname, the entire group appears as part of the DD statements 
for the step. 

The system will search the libraries for the program in the order in which the DD statements 
defining the libraries are coded. 



Using Private Catalogs 



Use Access Method Services to define private user catalogs, as explained in OS/VS Virtual 
Storage Access Method (VSAM) Programmer's Guide. The primary function of the 
special ddnames STEPCAT and JOBCAT is to change the order of the search of the catalogs to 
cause the STEPCAT and jobcat catalogs to be searched first. JOBCAT applies to each step of a 
job in which a STEPCAT has not been specified. To locate a data set, VSAM searches catalogs 
in the following order: 

1. User catalogs specified in the current job step (STEPCAT), or user catalogs specified in 
the current job (JOBCAT), if no user catalogs are specified for the job step. 

2. A CVOL or user catalog indicated by the first qualifier of the data set name, if any. 

3. The master catalog. 



Temporary Libraries 



Temporary libraries are libraries that are created and deleted within the job. It is not necessary 
to define a temporary library on a JOBLIB DD or STEPLIB DD statement: simply code a DD 
statement creating a partitioned data set and adding the program to it in the step that produces 
the program. You can then retrieve this program in a subsequent step. (You can also use the 
VIO facilities to define temporary data sets. For more information, refer to "Defining a VIO 
Temporary Data Set" later in this section.) 

For example, STEP2 illustrated below calls the program lEWL, which linkage edits object 
modules to form a load module that can be executed. Place the results of the Unkage edit step 
in a library so that a subsequent step can use those results. Since the results are not a program 
other jobs will call, it is logidal to place the program in a temporary library: 

PGM=IEWL 

DSNAME=£SPARTDS( PROG ) , UNIT=23 1 4 , 
DISP=( NEW, PASS ) , SPACE=( 1 024 ,(50,20,1 ) ) 
PGM=* . STEP2 . SYSLMOD 

Call the program in STEP3 by naming the step in which the hbrary was created and the 
name of the DD statement that defines the program as a member of a library. If STEP2 had 
called a procedure, and the DD statement named SYSLMOD was included in PR0CSTEP3 of the 
procedure, you would code pgm=*.step2.procstep3.syslmod. 



//STEP2 
//SYSLMOD 


EXEC 
DD 


//STEP3 


EXEC 



Defining a Diunmy Data Set 



i 



i 



To save processing time, you might not want a data set to be processed every time the job is 
executed. For example, while testing a program, you might want to suppress the writing of an 
output data set until you are sure it will contain meaningful output; you might want to skip the 
reading of a data set to be used only once a week. When defining a dummy data set, 
input/output operations are bjrpassed, disposition processing is not performed, and devices and 
storage are not allocated to the data set. 

Define a dummy data set by: 

• Coding the DUMMY parameter on the DD statement. 

• Assigning the data set name NULLFILE in the DSNAME parameter on the DD statement. ■ 
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Coding the DUMMY Parameter 

Code DUMMY as the first parameter on the DD statement. DUMMY is a positional parameter: it 
must precede all keyword parameters on the DD statement. 

When the DUMMY parameter is coded, all other parameters on the DD statement, with the 
exception of the DCB parameter, are ignored. (The parameters are checked for syntax, 
however; if a parameter is coded incorrectly, a JCL error message is issued.) Therefore, 
although you can code UNIT, VOLUME, and DISP, no devices or external storage is allocated to 
the data set and no disposition processing is performed. The DCB parameter must be coded if 
you would code it for normal I/O operations. For example, when an OPEN routine requires a 
BLKSIZE specification to obtain buffers and BLKSIZE is not specified in the DCB macro 
instruction, you should supply this information in the DCB parameter on the DD statement. 

When a DD statement that overrides a procedure DD statement contains the DUMMY 
parameter, all of the parameters coded on the procedure DD statement are nuUified, except for 
the DCB parameter. 

If you request unit or volume affinity with a dummy data set, the data set requesting 
affinity is assigned a dummy status. (Unit and volume affinity is described in the chapter 
"Requesting Units and Volumes.") 

When you want the data set to be processed, replace the DD statement containing the 
DUMMY parameter with a DD statement containing the parameters required to define the data 
set. When a procedure DD statement contains the DUMl^Y parameter, nullify it by coding the 
DSNAME parameter on the overriding DD statement and assigning a data set name other than 
NULLFILE. 

Coding DSNAME=NULLFILE 

Assigning the name NULLFILE in the DSNAME parameter has the same effect as coding 
DUMMY. The data set is assigned a dummy status; no devices or storage is allocated and no 
disposition processing is performed. All parameters except for DSNAME and DCB are ignored. 
(Code the DCB parameter when defining a dummy data set if you would code it for normal 
I/O operations.) 

When you want the data set to be processed, replace the name NULLFILE with another data 
set name. (Assigning names to data sets is described under "Specifying the DSNAME 
Parameter.") 

Requests to Read or Write a Dummy Data Set 

When the program asks to read a dummy data set, an end-of-data-set exit is taken 
immediately. When the program requests that the data set be written, the request is recognized 
but no data is transmitted. VSAM supports dummy data sets for both read and write 
processing. Otherwise, use the basic sequential access method (bsam) or queued sequential 
access method (QSAM) when requesting to write a dummy data set; if any other access method 
is used, the job is terminated. 

If you define a data set as a dummy data set, the DiSP parameter, if coded, is ignored and 
disposition processing is not performed. 
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Using Virtual Input/Output (VIO) for Temporary Data Sets 

Temporary data sets can be handled by a new facility called virtual I/O (viO). (viO processing 
does not apply to nontemporary data sets.) Data sets for which VIO is specified reside within 
the paging space; however, to a problem program and the access method, the data sets appear 
to reside on some other real direct access storage device. 

During system generation, new and/or existing unit names can be defined as eUgible for 
VIO. These unit names can be coded on a DD statement defining a data set to specify VIO 
processing for any system-named temporary data set. 

Defining a VIO Temporary Data Set 

The DD statement for a VIO data set is similar to the DD statement for a conventional 
temporary data set, with the following exceptions: 

• The UNIT ke5^word in the VIO DD statement must specify a name that has been defined as 
eligible for VIO. 

• If the SPACE parameter is not coded for virtual I/O data sets, the default value is 10 
primary and 50 secondary blocks with an average block length of 1000. Up to a one volume 
Umit, you wiU always obtain the full amount of space requested (that is, the primary 
quantity plus fifteen secondary requests). If the primary quantity for space is larger than the 
simulated volume, the job will fail. If the primary request is met, but the secondary request 
is greater than one volume, you will get up to one volume. When allocating by average 
block length for a VIO data set, the secondary request is determined by the average block 
length specified in the SPACE parameter. 

• VIO does not support ISAM or VSAM, so you can not specify ISAM or VSAM indicators in the 
DSORG parameter of a DD statement for a VIO data set. The "area" of an ISAM data set , 
cannot be specified in the DSNAME parameter. ■ 

• The DISP parameter must be specified as NEW or PASS when creating a data set. Do not ' 
specify KEEP or CATLG any time for the DISP parameter. 

• The DSNAME parameter need not be coded, but if it is, it must only be specified in & name 
form. 

• Volume serial numbers cannot be specified for VIO. A VIO data set will be allocated to 
non-vio if any of the above exceptions are violated, except the SPACE parameter request. 

• The unit count subparameter of the UNIT parameter is ignored. 

Backward References to VIO Data Sets 

If the referring DD statement (V0L=REF=) defines a temporary data set and refers to a DD 
statement that defines a VIO data set, the data set is assigned to external page storage as a VIO 
data set. 

If the referring DD statement requests unit affinity but does not define a temporary data set, 
the referring statement assumes the unit specification of the DD statement to which reference 
is made, but not the VIO status. 

The following examples assume that the user-assigned group name SYSDA and the device 
type name 3330 have been defined at system generation with the UNITNAME macro instruction 
as group names eligible for VIO processing. 

The data sets defined by the following DD statements are assigned to external page storage 
for VIO processing: 

//DD1 DD UNIT=SYSDA 



//DD2 DD UNIT=3330 
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//DD3 



DD 



DSN=&&A,DISP=(NEW),SPACE=(CYL,(.30,10 ) ),UNIT=SYSDA 



//DD1 
//DD2 



DD UNIT=SYSDA 
DD V0L=REF=*.DD1 



//DDA DD UNIT=SYSDA 

//DDB DD VOL=REF=*.DDA,UNIT=3330 

In each of the following examples, the data set defined on the first DD statement is assigned 
to external page storage for VIO processing. The second DD statement does not request VIO 
because it defines a nontemporary data set. 

//DD1 DD UNIT=SYSDA 

//DD2 DD DSN=NONTEMP , DISP=( , KEEP ) , 

// VOL=REF=* .DD1 , SPACE=( CYL, 1 ) 



//DD1 DD UNIT=SYSDA 

//DD2 DD DSN=TEMP , DISP=( , KEEP ) , VOL=SER=66543 1 , 

// SPACE=( CYL, 10), UNIT=AFF=DD1 

Using Virtual Input /Output (VIO) to Pass Temporary Data Sets Among Job Steps 

VIO data sets are passed the same as conventional data sets. For example, the following JCL 
statements show the DD statements required by VIO for a job with compilation, linkage editor, 
and go steps. The VIO data sets in the various job steps are defined as system-named 
temporary data sets. The unit name PAGEDEV has been defined as eligible for VIO with the 
UNITNAME macro instruction during system generation. 



( 1 ) //ASM 



EXEC 



PGM=IFOX00 



//ASM.SYSGO DD 
(2) //LKED EXEC 
//SYSLIN DD 
// DD 

//SYSLMOD DD 
// 



DSN=&&OBJ,UNIT=PAGEDEV,DISP=( NEW, PASS) 

PGM=IEWL 

DSN=S&OBJ,DISP=( OLD, DELETE) 

DDNAME=SYSIN 

DSN=S&LOAD( A ) ,DISP=( NEW, PASS ) ,UNIT=PAGEDEV, 

DCB=DSORG=PO 



(3) //GO 



EXEC 



PGM=* . LKED . SYSLMOD 



Entering Data Through the Input Stream 

You can enter data through the input stream by coding either the * or DATA parameters on 
the DD statements. The DD * statement precedes data in an input stream; the DD DATA 
statement precedes data in an input stream when the data contains JCL statements. The DLM 
parameter allows the use of a delimiter other than /* to terminate data defined in the input 
stream. Code this parameter on either the DD * or DD DATA parameters. 

You can include several distinct groups of data in the input stream. Two types of data are 
for job steps specifying a program name or for job steps that call a cataloged or in-stream 
procedure. However, cataloged and in-stream procedures cannot contain DD statements 
defining data in the input stream. 
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VSAM Data Sets 
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Virtual Storage Access Method (vSAM) is an access method of OS/VS for use with 
direct-access storage. It is different from all other access methods and you need to take certain 
precautions when coding VSAM data sets. You can use JCL parameters to identify cataloged 
VSAM data sets and to specify options for them. To process a VSAM data set, specify a DD 
statement in the form: 

//ddname DD DSNAME=dsname,DISP= JOLD? 

<SHRN 

The DSNAME parameter specifies the name of the cluster to which the data set you are 
processing belongs. The DISP parameter must specify either OLD or SHR because the data set is 
cataloged. You cannot use JCL to create VSAM data sets; you must use Access Method 
Services commands. VSAM data sets cannot be passed within a job. 

Some DD parameters and subparameters have different meanings for VSAM data sets. For 
example, VSAM data sets are described by the access-method control block (acb), not the 
DCB. Therefore, the DCB parameter is not applicable to VSAM. Parameters that can be used 
without modification are explained in Figure 13; parameters that either should not be used or 
should be used only with caution are explained in Figure 14. The STEPCAT and JOBCAT 
facilities identify user catalogs. These parameters are similarly used for all data sets and are 
discussed in this section under "Creating and Using Private Libraries." 

VSAM has one JCL parameter of its own: AMP. The AMP parameter takes effect when the 
data set defined by the DD statement is opened. It has subparameters for: 



Overriding operands specified with the ACB, EXLST, or the GENCB macro instructions. 

Supplying operands missing from the ACB or GENCB macro instruction. 

Indicating checkpoint/restart options. 

Indicating options when using ISAM macro instructions to process a key-sequenced data set. 

Indicating that the data set is a VSAM data set when you specify unit and volume 

information or DUMMY in a DD statement. 

Indicating that you want VSAM to supply storage dumps of the access-method control 

block(s) that identify this DD statement. 
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Parameter 


Subparameter 


DDNAME 


ddname 


DISP 


SHR 





OLD 


DSNAME 


dsname 


DUMMY 




UNIT 


address 




type 




group 




P 




unit count 



VOLUME 



DEFER 

PRIVATE 

SER 



G)mment 

Works as in OS/VS. 

Indicates that you are willing to share the data set with other jobs. This 
subparameter alone, however, does not guarantee that sharing will take place. See 
OS/VS Virtual Storage Access Method (VSAM) Programmer's Guide for a full 
description of data-set sharing. 

Works as in OS/VS. 

Works as in OSA^S. 

Works as in OS/VS, except that an attempt to read results in an end-of-data 
condition, and an attempt to write results in a return code that indicates the write 
was successful. If specified, AMP=AMORG must also be specified. 

Must be the address of a vaUd device for VSAM (2305, 2314, 2319, 3330V, 3330, 
3340, 3344, or 3350). If not, OPEN will fail. 

Must be a type supported by VSAM"(2305T2314, 3330, 3330V, 3340, or 3350). 
Ifnot, OPEN will fail. 

Must be a group supported by VSAM. If not, OPEN will fail. 

There must be enough units to mount all of the volumes specified. If sufficient 
units are available, UNIT=p can improve performance by avoiding the mounting 
and demounting of volumes. 

If the number of devices requested is greater than the number of volumes on which 
the data set resides, the extra devices are allocated anyway. If a key-sequenced 
data set and its index reside on unlike devices, the extra devices are allocated evenly 
between the unlike device types. If the number of devices requested is less than the 
number of volumes on which the data set resides but greater than the minimum 
number required to gain access to the data set, the devices over the minimum are 
allocated evenly between unUke device types. If devices beyond the count specified 
are in use by another task but are shareable and have mounted on them volumes 
containing parts of the data set to be processed, they will also be allocated to this 
data set. 

Works as in OS/VS. 

Works as in OS/VS. 

r' 

The volume serial number(s) used in the Access Method Services DEFINE command 
for the data set must match the volume serial numbers in the VOLUME=SER 
specification when the data set is defined. After a VSAM data set is defined, the 
volume serial number(s) need not be specified on a DD statement to retrieve or 
process the data set. If, however, VOLUME=SER and UNIT=type are specified, 
only those volumes specifically named are initially mounted. Other volumes may 
be mounted when they're needed if at least one of the units allocated to the data 
set is not shareable or the unit count is equal to the total number of volumes 
allocated to the data set. A unit is unshareable when unit count is less than the 
number of volume serial numbers specified or when DEFER is specified. 



Figure 13. DD parameters used with VSAM 
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Parameter 
DATA 

DCB 



DISP 



DSNAME 



LABEL 



Subparameter 

All 

CATLG 

DELETE 
MOD 

KEEP 

NEW 



UNCATLG 



PASS 



dsname(areaname) 

dsname( generation) 

dsname( member) 

All temporary 
dsnames 

All backward 
DD references 
of the form 
*.ddname 

BLP, NL, NSL 

IN 

OUT 

NOPWREAD 



Comment 

Because there is no way to get VSAM data into the input stream, this 
parameter is not applicable to VSAM. 

The access-method control block, not the DCB, describes VSAM data sets; 
therefore, the DCB parameter is not appUcable to VSAM. An access-method 
control block is generated by an ACB or GENCB macro, and can be modified 
by a MODCB macro. 

VSAM data sets are cataloged and uncataloged as a result of an Acess Method 
Services command; if CATLG is coded, a message is issued, but the data set 
is not cataloged. 

VSAM data sets are deleted as a result of an Acess Method Services command; 
if DELETE is coded, a message is issued, but the data set is not deleted. 

For VSAM data sets, MOD is treated as if OLD were specified, except for 
processing with an ISAM program, in which case MOD indicates resume load. 

Because KEEP is implied for VSAM data sets, it need not be coded. 

VSAM data spaces are initially allocated as a result of the Access Method 
Services DEFINE command. If NEW is specified, OS/VS also allocates space, 
and it is never used by VSAM. Moreover, an Access Method Services request 
for space may fail if the DISP=NEW acquisition of space causes too little space 
to remain available. 

VSAM data sets are cataloged and uncataloged as a result of Access Method 
Services commands; if UNCATLG is coded, a message is issued, but the data 
set is not uncataloged. 

The PASS parameter is not applicable to VSAM. However, because there is no 
error checking, coding PASS for a key-sequenced data set whose index resides 
on a like device does not result in an error. If a VSAM data set and its 
index reside on unlike devices, the results are unpredictable. In either case, the 
data set is not passed. 

The name is used; areaname is ignored. 

The name is used; generation is ignored. 

The name is used; member is ignored. 

Because VSAM data sets are built by Access Method Services, which uses the 
data-set name supplied in the DEFINE command, temporary names cannot 
be used with VSAM. 

If the object referred to is a cluster and the data set and index reside on 
unlike devices, the results of a backward DD reference are unpredictable. 



Because these subparameters have no meaning for direct-access devices, they 
do not apply for VSAM data sets, which all reside on direct-access storage. 

Because IN is used to override DCB subparameters and the DCB parameter 
does not apply to VSAM data sets, IN does not apply. 

Because OUT is used to override DCB subparameters and the DCB parameter 
does not apply to VSAM data sets, OUT does not apply. 

The password-protection bit is set for all VSAM data sets, regardless of the 
PASSWORD/NOPWREAD specification in the LABEL parameter. 



It: 



Figure 14. DD parameters you should avoid with VSAM (Part 1 of 2) 
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Parameter Subparameter 
PASSWORD 



SL, SUL 



SPACE 



SYSOUT 

UCS M 

UNIT AFF 

VOLUME REF 



vol seq number 
vol count 



Comment 

The pa&word-protection bit is set for all VSAM data sets, regardless of the 
PASSWORD/NOPWREAD specification in the LABEL parameter. 

Although these parameters apply to direct-access storage devices, SL is always 
used for VSAM, whether you specify SL, SUL, or neither. 

VSAM data spaces are initially allocated as a result of the Access Method 
Services DEFINE command. If SPACE is specified, therefore, an extent is 
allocated that is never used by VSAM. Moreover, an Access Method Services 
request for space may fail as a result of the SPACE acquisition of space. 

If SYSOUT is coded with a mutually exclusive parameter (for example, DISP), 
the job step is terminated with an error message. 

Because this parameter applies only to unit-record devices, it does not apply to 
VSAM. 

You must use this subparameter carefully. If the cluster components, the 
data and its index, reside on unlike devices, the results of UNIT=AFF are 
unpredictable. 

You must use this subparameter carefully. If the referenced volumes are not 
a subset of those contained in the catalog record for the data set, the results 
are unpredictable. 

Results are unpredictable. 

This subparameter is used to request some number of nonspecific volumes. 
Because all VSAM volumes must be specifically defined before processing, 
volcount is not appHcable to VSAM data sets. 

Because there is no way to get VSAM data into the input stream, this 
parameter has no application with VSAM. 



Figure 14. DD parameters you should avoid with VSAM (Part 2 of 2) 
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Creating and Retrieving Indexed Sequential Data Sets 

Indexed sequential (ISAM) data sets are created and retrieved using special subsets of DD 
statement parameters and subparameters. Each data set can occupy up to three different areas 
of space: 

1. Prime area — This area contains data and related track indexes. It exists for all indexed 
sequential data sets. 

2. Overflow area — This area contains overflow from the prime area when new data is 
added. It is optional. 

3. Index area — This area contains master and cylinder indexes associated with the data 
set. It exists for any indexed sequential data set that has a prime area occupying more 
than one cylinder. 

Indexed sequential data sets must reside on direct access volumes. The data set can reside 
on more than one volume and the device types of the volumes may in some cases differ. 

Creating an Indexed Sequential Data Set 

One to three DD statements can be used to define a new indexed sequential data set. When 
using three DD statements to define the data set, each DD statement defines a different area 
and the areas must be defined in the following order: 

1. Index area. 

2. Prime area. 

3. Overflow area. 

When using two DD statements to define the data set, the areas must be defined in the 
following order: 

1. Index area. 1. Prime area, (optionally, Index area) 

or 

2. Prime area. 2. Overflow area. 

When using one DD statement to define the data set, you are defining the prime area and, 
optionally, the index area. 

When more than one DD statement is used to define the data set, assign a ddname only to 
the first DD statement; the name field of the other statements must be blank. 

The only DD statement parameters that can be coded when defining a new indexed 
sequential data set are the dsname, unit, volume, label, dcb, disp, and space 
parameters. When to code each of these parameters and what restrictions apply are described 
in the following paragraphs. 

The DSNAME Parameter 

The DSNAME parameter is required on any DD statement that defines a new temporary or 
nontemporary indexed sequential data set. To identify the area you are defining, you follow 
the DSNAME parameter with the area: DSNAME=name(lNDEX). DSNAME=name(PRlME), or 
DSNAME=name(OVERFLOW). If you are using only one DD statement to define the data set, 
code DSNAME=name(PRlME) or DSNAME=name. 

When reusing previously allocated space to create an ISAM data set, the DSNAME parameter 
must contain the name of the old data set to be overlaid. 
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The UNIT Parameter 



The UNIT parameter is required on any DD statement that defines a new indexed sequential 
data set unless VOLUME=REF=reference is coded. You must request a direct access device in 
the UNIT parameter and must not request DEFER. 

If there are separate DD statements defining the prime and index areas, request the same 
number of direct access devices for the prime area as there are volumes specified in the 
VOLUME parameter. You request only one direct access volume for an index area and one for 
an overflow area. 

A DD statement for the index area or overflow area can request a device tjfpe different than 
the t)rpe requested on the other statements. 

Another way to request a device is to code UNlT=AFF=ddname (except for new data sets), 
where the named DD statement requests the direct access device or device type you want. 



The VOLUME Parameter 



The VOLUME parameter is required only if you want an area of the data set written on a 
specific volume or the prime area requires the use of more than one volume. (If the prime area 
and index area are defined on the same statement, you cannot request more than one volume 
on the DD statement.) Either supply the volume serial number or numbers in the VOLUME 
parameter or code VOLUME=REF=reference. In all cases, the VOLUME parameter can be used 
to request a private volume (PRIVATE). 

Notes: 

1. If a new ISAM data set is bemg created with a nonspecific volume request and its DSNAME 
already exists on a volume eligible for allocation, the job might fail due to duplicate names on 
the volume. If the volume selected for the new data set akeady contains a data set with the 
same name, the job fails. If the old data set with a duplicate name resides on another volume 
than the one selected for the new data set, however, th new data set is not affected and will 
be added to the volume. Failure of this t5rpe can be corrected by either scratching the old data 
set or renaming the new data set before resubmitting the job. 

2. If a nonspecific volume request is made for an ISAM data set and space is not available on 
the volume selected for allocation, the job faUs. 



The LABEL Parameter 



The LABEL parameter need only be coded to specify a retention period (EXPDT or RETPD) or 
password protection (PASSWORD). 



The DCB Parameter 



The DCB parameter must be coded on every DD statement that defines an indexed sequential 
data set. At minimum, the DCB parameter must contain DS0RG=IS or DS0RG=ISU. Other DCB 
subparameters can be coded to complete the data control block if it has not been completed 
by the processing program. When more than one DD statement is used to define the data set, 
code all the DCB subparameters on the first DD statement. Code DCB=*.ddname on the 
remaining statement or statements; ddname is the name of the DD statement that contains the 
DCB subparameters. 

When reusing previously allocated space and recreating an ISAM data set, desired changes in 
the DCB parameter must be coded on the DD statement. Although you are creating a new data 
set, some DCB subparameters cannot be changed if you want to use the space the old data set 
used. The DCB subparameters you can change are: BFALN, BLKSIZE, CYLOFL, DSORG, 
KEYLEN, LRECL, NCP, NTM, OPTCD, RECFM, and RKP. 
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The DISP Parameter 



If you are creating a new data set and not reusing preallocated space, the DISP parameter need 
only be coded if you want to keep, DISP=(,KEEP), catalog, DISP=(,CATLG), or pass, 
DISP=(,PASS), the data set. If reusing previously allocated space and recreating an ISAM data 
set, code DISP=0LD. The newly created data set will overlay the old one. 

In order to catalog the data set when disp=(,CATLG) is coded or pass the data set when 
DISP=(,PASS) is coded, the data set must be defined on only one DD statement. If the data set 
was defined on more than one DD statement and the volumes on which the data set now 
resides correspond to the same device type, use the Access Method Services DEFINE command 
to catalog the data set. Refer to the OS/VS2 Access Method Services publication for details. 



The SPACE Parameter 



The SPACE parameter is required on any DD statement that defines a new indexed sequential 
data set. Use either the recommended nonspecific allocation technique or the more restricted 
absolute track (abstr) technique. If more than one DD statement is used to define the data 
set, all must request space using the same technique. 



Nonspecific Allocation Technique 



You must request the primary quantity in cyUnders (CYL). When the DD statement that defines 
the prime area requests more than one volume, each volume is assigned the number of 
cylinders requested in the SPACE parameter. 

One of the subparameters of the SPACE parameter, the "index" subparameter, is used to 
indicate how many cyUnders are required for an index. When one DD statement is used to 
define the prime and index areas and you want to exphcity state the size of the index, code 
the "index" subparameter. 

The CONTIG subparameter can be coded in the SPACE parameter. However, if CONTIG is 
coded on one of the statements, it must be coded on all of them. 

You cannot request a secondary quantity for an indexed sequential data set. Also, you 
cannot code the subparameters RLSE, MXIG, ALX, and ROUND. 



Absolute Track Technique 



The number of tracks requested must be equal to one or more whole cyUnders. The address of 
the beginning track must correspond with the first track of a cylinder other than the first 
cyUnder on the volume. When the DD statement that defines the prime area requests more 
than one volume, space is aUocated for the prime area beginning at the specified address and 
continuing through the volume and onto the next volume untU the request is satisfied. (This 
can only be done if the volume table of contents of the second and aU succeeding volumes is 
contained within the first cyUnder of each volume.) 

One of the subparameters of the SPACE parameter, the "index" subparameter, is used to 
indicate how many tracks are required for an index. The number of tracks specified must be 
equal to one or more cyUnders. When one DD statement is used to define the prime and index 
areas and you want to expUcity state the size of the index, code the "index" subparameter. 

Note: If the indexed sequential data set is to reside on more than one volume and an error is 
encountered as the volumes are being allocated to the data set, follow this procedure before 
resubmitting the job: Use the lEHPROGM utiUty program to scratch the data set labels on any 
of the volumes to which the data set was successfully aUocated. This utiUty program is 
described in the chapter "The lEHPROGM Program" in OS/VS Utilities. 
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Area Arrangement of an Indexed Sequential Data Set 

When creating an indexed sequential data set, the arrangement of the areas is based on two 
criteria: 

1. The number of DD statements used to define the data set. 

2. What area each DD statement defines. 

An additional criterion is used when you do not include a DD statement that defines the 
index area: 

3. Is an index size coded in the SPACE parameter on the DD statement that defines the 
prime area? 

Figure 23 in the "Reference Tables" section illustrates the different arrangements that can 
result based on the criteria listed above. In addition, it indicates what restrictions apply on the 
number and t)rpes of devices that can be requested. 

Retrieving an Indexed Sequential Data Set 

If aU areas of an existing indexed sequential data set reside on volumes of the same device 
type, you can retrieve the entire data set with one DD statement. If the index or overflow 
resides on a volume of a different device type, use two DD statements. If the index and 
overflow reside on volumes of different device types, use three DD statements to retrieve the 
data set. The DD statements are coded in the following order: 

1. First DD statement - defines the index area 

2. Second DD statement - defines the prime area 

3. Third DD statement - defines the overflow area 

The only DD statement parameters that can be coded when retrieving an indexed sequential 
data set are the DSNAME, UNIT, VOLUME, DCB, and DISP parameters. When to code each of 
these parameters and what restrictions apply are described in the following paragraphs. 

The DSNAME Parameter 

The DSNAME parameter is always required. Identify the data set by its name, but do not 
include the term INDEX, PRIME, or OVFLOW. If the data set was passed from a previous step, 
identify it by a backward reference. 

The UNIT Parameter 

The UNIT parameter must be coded unless the data set resides on one volume and was passed. 
You identify in the UNIT parameter the device type and how many of these devices are 
required. 

If the data set resides on more than one volume and the volumes correspond to the same 
device t3rpe, you need only one DD statement to retrieve the data set. Request one device in 
the UNIT parameter per volume. If the index or overflow area of the data set resides on a 
different type of volume than the other areas, you must use two DD statements to retrieve the 
data set. On one DD statement, request the device type required to retrieve the index or 
overflow area. On the other DD statement, request the device type and the number of devices 
required to retrieve the prime area and the overflow area if the overflow area resides on the 
same device type. If the index and the overflow areas reside on different device types from the 
prime area, a third DD statement is needed. 
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The VOLUME Parameter 



i 

The VOLUME parameter must be coded unless the data set resides on one volume and was 
passed from a previous step. Identify in the VOLUME parameter the serial numbers of the 
volumes on which the data set resides. Code the serial numbers in the same order as they were 
coded on the DD statements used to create the data set. 



The DCB Parameter 



I The DCB parameter must be coded unless the data set was passed from a previous step or is 
cataloged. The DCB parameter must always contain DSORG=lS or DS0RG=ISU. Other DCB 
subparameters can be coded to complete the data control block if it has not been completed 
by the processing program. 

The DISP Parameter 

The DISP parameter must always be coded. The first subparameter of the DISP parameter must 
be SHR or OLD. You can, optionally, assign a disposition as the second subparameter. 

Examples of Creating and Retrieving an Indexed Sequential Data Set 

The following job creates an indexed sequential data set on one 3330 volume. 

//ISAMJOB JOB , ,MSGLEVEL=( 1 , 1 ) ,PERFORM=25 

PGM= INCLUDE 

DSN=DATASET1 ( INDEX ) , DISP=( NEW, KEEP ) , UNIT=3330 , 
VOL=SER=777777,SPACE=(CYL,( 10), ,CONTIG), 
DCB=(DSORG=IS,RECFM=F,LRECL=80,RKP=1 ,KEYLEN=8 ) 
DSN=DATASET1 ( PRIME ) ,DISP=( NEW, KEEP ) ,UNIT=3330, 
V0L=REF=*.DD1 , SPACE=( CYL, ( 25), ,CONTIG ) ,DCB=* .DDI 
DSN=DATASET1 ( OVFLOW ) ,DISP=( NEW, KEEP ) ,UNIT=3330, 
VOL=REF=* .DDI ,SPACE=( CYL, ( 25 ) , ,CONTIG ) , DCB=* .DDI 

The following job includes the DD statements required to retrieve the indexed sequential 
data set created above. 

//RETRISAM JOB , ,MSGLEVEL=( 1 , 1 ) ,PERFORM=25 

//STEP1 EXEC PGM=RETRIEVE 

//DDISAM DD DSN=DATASET1 ,DCB=DSORG=IS,UNIT=3330,DISP=OLD, 

// VOL=SER=777777 

The following job creates an indexed sequential data set on one 3330 and two 2314 
volumes. 

, ,MSGLEVEL=( 1 , 1 ) ,PERFORM=25 

PGM=IEFISAM 

DSN=DATASET2 ( INDEX ) ,DISP=( NEW, KEEP ) , UNIT=3330 , 

V0L=SER=888888 , SPACE=( CYL ,10,, CONTIG ) , DCB=( DSORG=IS , 

RECFM=F,LRECL=80,RKP=1 ,KEYLEN=8 ) 

DSN=DATASET2 ( PRIME ) , DISP=( , KEEP ) , UNIT=23 1 4 , 

VOL=SER=999999 , SPACE=( CYL ,10,, CONTIG ) , DCB=* . DDISAM 

DSN=DATASET2 ( OVFLOW ) , DISP=( ,KEEP ) , UNIT=23 1 4 , 

VOL=SER=AAAAAA,SPACE=(CYL, 10, , CONTIG ) ,DCB=* .DDISAM 



//STEP1 


EXEC 


//DDI 


DD 


// 




// 




// 


DD 


// 




// 


■DD 


// 





% 



//ISAMJOB 


JOB 


//STEP1 


EXEC 


//DDISAM 


DD 


// 




// 




// 


DD 


// 




// 


DD 


// 
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The following job includes the DD statements required to retrieve the indexed sequential 
data set created above. 

//RERISAM JOB , ,MSGLEVEL=( 1 , 1 ) ,PERFORM=25 

//STEP1 EXEC PGM=IEFISAM 

//DDISMA DD DSN=DATASET2 , DCB=DSORG=IS . DISP=OLD, UNIT=3330 , 

// VOL=SER=888888 

// DD DSN=DATASE'r2,DCB=DS0RG=IS,DISP=0LD,UNIT=( 2314,2 ), 

// VOL=SER=( 999999, AAAAAA) 

Creating and Retrieving Generation Data Sets 

A generation data set is one of a collection of successive, historically related, cataloged data 
sets known as a generation data group. The system keeps track of each data set in a 
generation data group as it is created so that new data sets can be chronologically ordered and 
old ones easily retrieved. 

To create or retrieve a generation data set, identify the generation data group name in the 
DSNAME parameter and follow the group name with a relative generation number. When 
creating a generation data set, the relative generation number t«lls the system whether this is 
the first data set being added during the job, the second, the third, etc. When retrieving a 
generation data set, the relative generation number tells the system how many data sets have 
been added to the group since this data set was added, 

A generation data group can consist of cataloged sequential, partitioned, and direct data sets 
residing on tape volumes, direct access volumes, or both. If the generation data group resides 
on more than one device type, all generations cannot be retrieved together. Generation data 
sets can have like or unlike DCB attributes and data set organizations. If the attributes and 
organizations of all generations in a group are identical, the generations can be retrieved 
together as a single data set (up to 255 data sets can be retrieved in this way). 

Building a Generation Data Group Base Entry 

Before defining the first generation data set, build a generation data group base entry in a 
VSAM or OS CVOL catalog. This provides for as many generation data sets (up to 255) as you 
would like to have in the generation data group. The system uses the base to keep track of the 
chronological order of the generation data sets. Use the Access Method Services DEFINE 
command to build generation data group bases in a VSAM catalog. This command is described 
I in OS/VS2 Access Method Services. 

Another requirement of generation data groups is that a data set label list exist on the same 
volume as the catalog. The system uses this label to refer to DCB attributes when you define a 
new generation data set. There are two ways to satisfy this requirement: (1) create a model 
data set label before defining the first generation data set; or (2) use the DCB parameter to 
refer the system to an existing cataloged data set each time you define a new generation data 
set. 

Creating a Model Data Set Label 

To create a model data set label, define a data set and request that it be placed on the same 
volume as the generation data group base. This ensures that there is always a data set label on 
the same volume as the catalog to which the system can refer. 

The name assigned to the data set can be the same or different than the name assigned to 
the generation data group. (If you assign the same name for both, the data set associated with 
the model data set label cannot be cataloged.) Request a space allocation of zero tracks or 
cylinders. The DCB attributes that can be suppUed are DSORG, OPTCD, BLKSIZE, LRECL, 
KEYLEN, and RKP. 
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You need not create a model data set label for every generation data group whose indexes 
reside on the same volume. Instead, create one model data set label to be used by any number 
of generation data groups. When creating a generation data set, specify the name of the model 
in the DCB parameter and follow the name with a Ust of all the DCB subparameters required 
for the new generation data set that are different than specified in the model; that is, 
DCB=(dsname,list of attributes). 

Referring the System to a Cataloged Data Set 

If there is a cataloged data set that resides on the same volume as the generation data group 
index and you are sure that data set will exist as long as you are adding data sets to the 
generation data group, you need not create a model data set label. When creating a generation 
data group, specify the name of the cataloged data set in the DCB parameter by coding 
DCB=dsname. If all the DCB attributes are not contained in the label of the cataloged data set, 
or if you want to override certain attributes, follow the data set name with these attributes; 
that is, DCB=(dsname,list of attributes). 

Creating a Generation Data Set 

When defining a new generation data set, always code the DSNAME, DISP, and UNIT 
parameters. Other parameters you might code are the VOLUME, SPACE, LABEL, and DCB 
parameters. 

The DSNAME Parameter 

In the DSNAME parameter, code the name of the generation data group followed by a number 
enclosed in parentheses. This number must be 1 or greater. If this is the first data set you are 
adding to a particular generation data group during the job, code + 1 in parentheses. Each time 
during the job you add a data set to the same generation data group, increase the number by 
one. 

Any time you refer to this data set later in the job, use the same relative generation number 
as was used earlier. At the end of the job, the system updates the relative generation numbers 
of all generations in the group to reflect the additions. 

Note: Unpredictable results can occur if you use a relative generation number that causes the 
actual generation number to exceed G9999. 



The DISP Parameter 



New generations should be assigned a status of NEW and a disposition of CATLG in the DISP 
parameter; that is, DISP=(new,CATLG). If the DISP parameter is not specified, the system 
assumes DISP=(NEW,DELETE) and the new generation will be deleted at the end of the step. 



The UNIT Parameter 



The UNIT parameter is required on any DD statement that defines a new generation data set 
unless VOLUME=REF=reference is coded. In the UNIT parameter, identify the type of devices 
you want (tape or direct access). 



The SPACE Parameter 



The SPACE parameter is coded only when the generation data set is to reside on a direct 
access volume. 
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The LABEL Parameter 



You can specify label type, password protection (PASSWORD), and a retention period (EXPDT 
or RETPd) in the label parameter. If the data set will reside on a tape volume and is not the 
first data set on the volume, specify a data set sequence number. 



The DCB Parameter 

A model data set label that has the same name as the group name may exist. If this is so, and 
if the label contains all the attributes required to define this generation, you need not code the 
DCB parameter. If all the attributes are not contained in the label, or if you want to override 
certain attributes, code DCB = (list of attributes). 

If a model data set label has a different name than the group name and if the label contains 
aU the attributes requhed to define this generation data set, only the name of the data set 
associated with the model data set label need be coded. Code the name in the DCB parameter, 
that is, DCB=dsname. If all the attributes are not contained in the label, or if you want to 
override certain attributes, follow the data set name with these attributes; that is, 
DCB=(dsname,list of attributes). 

If a model data set label does not exist, you must code the name of a cataloged data set 
that resides on the same volume as the generation data group index. If all the attributes are 
not contained in the label for this data set, or if you want to override certain attributes, follow 
the data set name with these attributes. 

Retrieving a Generation Data Set 

To retrieve a generation data set, always code the DSNAME and DISP parameters. Other 
parameters you might code are the UNIT, LABEL, and DCB parameters. 

The DSNAME Parameter 

In the DSNAME parameter, code the name of the generation data group followed by a number 
enclosed in parentheses. The number coded depends on how many new generation data sets 
have been added to the group since this generation data set was added. If none have been 
added prior to the job, code a zero (0). If one has been added prior to the job, code (-1). 
Reduce the number by 1 until you determine the present relative generation number of the 
data set, then code this number. 

Any time you refer to this data set later in the job, use the same relative generation number 
as was used earlier, even if another generation has been added during the job. 

Note: Relative generation numbers are based on the catalog as it existed at the start of the 
job, plus any changes made by cataloging new members of the data set during the job. 

If you want to retrieve all generations of a generation data group as a single data set, or 
retrieve all generations of a generation data group by concatenation, in order, starting with the 
most recent data set and with unit affinity to the most recent data set, specify the generation 
data group name without a generation number; for example, DSNAME=WEEKLY.PAYROLL. 
You can retrieve all generations by concatenating them only if the attributes and organization 
of all generations are identical. 

I Note: If concatenating and executing a RDJFCB macro instruction, only the first JFCB is read. 
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The DISP Parameter 



The DISP parameter must always be coded. The first subparameter of the DISP parameter must 
be OLD, SHR, or MOD. You can, optionally, assign a disposition as the second subparameter. 
The second subparameter must be specified for a generation data group. You should avoid 
coding PASS as the second subparameter when you retrieve all generations of a generation data 
group as a single data set. In all such retrievals the unit and volume information for each 
generation level is obtained from the catalog, and not from the pass mechanism. 



The UNIT Parameter 



Code the unit parameter when you want more than one device assigned to the data set. Code 
the number of devices you want in the unit count subparameter, or, if the data set resides on 
more than one volume and you want as many devices as there are volumes, code P in place of 
the unit count subparameter. 



The VOLUME Parameter 



You can assign a volume in the VOLUME parameter or let the system assign one for you. The 
VOLUME parameter can also be used to request a private volume (PRIVATE) and to indicate 
that more volumes can be required (volume count). A volume serial number for an old 
generation data group is ignored; the value used is in the catalog. 



The LABEL Parameter 



Code the label parameter when the data set has other than standard labels. If the data set 
resides on a volume and is not the first data set on the volume, specify the data set sequence 
number. 



The DCB Parameter 



Code the DCB parameter when the data set has other than standard labels and DCB 
information is required to complete the data control block. 



Submitting a Job for Restart 



Certain rules apply when you refer to generation data sets in a job submitted for restart (the 
RESTART parameter is coded on the JOB statement). 

jRw step restart: If step restart is performed, generation data sets that were created and 
cataloged in steps preceding the restart step must not be referred to in the restart step or in 
steps following the restart step by means of the same relative generation numbers that were 
used to create them. Instead, you must refer to a generation data set by means of its present 
relative generation number. For example, if the last generation data set created and cataloged 
was assigned a generation number of +2, it would be referred to as in the restart step and in 
steps following the restart step. In this case, the generation data set assigned number of + 1 
would be referred to as -1. 

For checkpoint restart: If generation data sets created in the restart step were kept instead of 
cataloged, that is, DISP=(NEW,CATLG,KEEP) was coded, you can, during checkpoint restart, 
refer to these data sets and generation data sets created and cataloged in steps preceding the 
restart step by means of the same relative generation numbers that were used to create them. 
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Example of Creating and Retrieving Generation Data Sets 

The following job step includes the DD statements that could be used to add three data sets to 
a generation data group. 

PGM=PROCESS 

DSNAME=A.B.C(+1 ) ,DISP=( NEW, CATLG ) ,UNIT=2400 , 
VOL=SER=13846,LABEL=( , SUL) 

DSNAME=A.B.C(+2),DISP=(NEW,CATLG),UNIT=3330, 
VOL=SER=1031 1 ,SPACE=(480,( 150,20 ) ) 
DSNAME=A. B . C( +3 ) , DISP=( NEW, CATLG ) , UNIT=23 1 4 , 
VOL=SER=28929,SPACE=(480,( 150,20) ), 
DCB=(LRECL=120,BLKSIZE=480 ) 



//STEPA 


EXEC 


//DD1 


DD 


// 




//DD2 


DD 


// 




//DD3 


DD 


// 




// 





The first two DD statements do not include the DCB parameter; therefore, a model data set 
label must exist on the same volume as the generation data group index and must have same 
name as the generation data group (A.B.C). Since the DCB parameter is coded on the third DD 
statement, the attributes LRECL and BLKSIZE, along with the attributes included in the model 
data set label, are used. 

The following job includes the DD statements required to retrieve the generation data sets 
defined above when no other data sets have been added to the generation data group. 

CLASS=B 

PGM=REP0RT9 

DSNAME=A.B.C(-2 ) ,DISP=OLD, LABEL=( , SUL) 

DSNAME=A . B . C( - 1 ) , DISP=OLD 

DSNAME=A . B . C( ) , DISP=OLD 



//JWC 


JOB 


//STEP1 


EXEC 


//DDA 


DD 


//DDB 


DD 


//DDC 


DD 
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Cataloged and In-Stream Procedures 



Applications that require many control statements and are used on a regular basis can be 
considerably simplified through the use of cataloged and in-stream procedures. A cataloged 
procedure is a set of job control statements that are placed in a partitioned data set known as 
the procedure Ubrary; an in-stream procedure is a set of job control statements that are placed 
in the input stream within a job. You can execute a procedure simply by specifying its name 
on an EXEC statement in your job. This section describes how to write and use cataloged and 
in-stream procedures. 

This section includes three topics: 

• Writing Cataloged and In-Stream Procedures 

• Using Cataloged and In-Stream Procedures 

• Using Symbolic Parameters 

Writing Cataloged and In-Stream Procedures 

Cataloged and in-stream procedures are simply the job control statements needed to perform 
an apphcation. A procedure contains one or more procedure steps, each step consisting of an 
EXEC statement that identifies the program to be executed and DD statements defining the 
data sets to be used or produced by the program. The program requested on the EXEC 
statement must exist in a private or the system library. If you do request a program that is 
contained in a private Ubrary, the procedure step caUing that program must include a a DD 
statement with the ddname STEPLIB that defines the private library; the STEPLIB DD statement 
is described in the chapter, "Creating and Using Private and Temporary Libraries." 

Cataloged and in-stream procedures cannot contain: 

• EXEC statements that refer to other cataloged or in-stream procedures; 

• JOB, delimiter, or null statements; 

• DD statements defining private Ubraries to be used throughout the job (DD statements with 
the ddname JOBLIB); 

• DD statements defining data in the input stream (statements including the * or DATA 
parameters). 

• Any JES2 control statements; they are ignored. 

• Any JES3 control statements; they are ignored in cataloged procedures only. 

Identifying an In-Stream Procedure 

To identify an in-stream procedure, code the PROC and PEND job control statements. 

On the PROC statement, which must be the first statement in an in-stream procedure, assign 
the procedure a name. This name is the name that a programmer codes to call the procedure. 
Optionally, you can also assign default values to synibolic parameters contained in the 
procedure and code comments. (A symboUc parameter is a symbol preceded by an ampersand 
that stands for a parameter, a subparameter, or a value in a procedure; including symboUc 
parameters in a procedure is described in detail in the chapter "Using Symbolic Parameters.") 
If you do not assign default values to symbolic parameters on the PROC statement, you cannot 
code comments. The simplest form of the PROC statement, to identify an in-stream procedure 
named PAYROLL, would be: 

//PAYROLL PROC 
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//SALES 


PROC 


//STEP1 


EXEC 


//DD1A 


DD 


//DD1B 


DD 


//STEP2 


EXEC 


//STEPLIB 


DD 


//DD2A 


DD 


// 


PEND 



The PEND statement marks the end of the in-stream procedure. You can include a name on 
the PEND statement and comments, but these are optional. Both of the following examples are ■ 

acceptable: 

//ENDPROC PEND end of in-stream procedure 
// PEND 

The following example illustrates an in-stream procedure named SALES consisting of two 
procedure steps. Note that STEP2 includes a STEPLIB DD statement to define the private library 
in which the program JUGGLE can be found. 

PGM=FETCH 

DSNAME=RECORDS( BRANCHES ) ,DISP=OLD 

DSNAME=RECORDS( MORGUE ) ,DISP-MOD 

PGM=JUGGLE 

DSNAME=PRIV.WORK,DISP=OLD 

SYSOUT=A 

Placing a Cataloged Procedure in a Procedure Library 

The major difference between cataloged and in-stream procedures is where they are placed. 
Cataloged procedures must be placed in a procedure library before being used. In-stream 
procedures are placed within the job that calls them. A procedure library is simply a 
partitioned data set containing cataloged procedures. IBM supplies a procedure library named 
SYSI.PROCLIB, but the installation can have additional procedure libraries with different names. 
When a programmer calls a cataloged procedure, he receives a copy of the procedure; 
therefore, a cataloged procedure can be used by more than one programmer simultaneously. 

To add a procedure to a procedure library, use the lEBUPDTE utility program. You can also m 

use the lEBUPDTE utility to permanently modify an existing procedure. (Before modifying an 
existing cataloged procedure, however, you must notify the operator; he must delay the 
execution of jobs that might use the procedure library while it is being updated.) Details on 
using the lEBUPDTE utility are included in OS/VS Utilities. In JES3, you can use the procedure 
library update feature to modify an existing procedure. The UPDATE parameter on the JES3 
MAIN statement indicates that a procedure library is being updated and causes all jobs using 
the Ubrary to be held until the update is complete. Before placing or modifying a cataloged 
procedure in a procedure library, test it without overriding any parameters to ensure that the 
procedure statements are syntactically correct. Additionally, test the procedure by first running 
it as an in-stream procedure. 

No special job control statements are used to identify a cataloged procedure. The PEND 
statement is never used and the PROC statement is optional. You need code the PROC 
statement as the first statement in a cataloged procedure only when you want to assign default 
values to symbolic parameters. The name of the PROC statement is not necessarily the name of 
the cataloged procedure; you assign the procedure a name when adding it to the procedure 
library. 

Allowing for Changes in Cataloged and In-Stream Procedures 

The usefulness of cataloged and in-stream procedures is destiroyed if a programmer who uses 
the procedure has to permanently modify the procedure every time he wants to make a 
change. When writing a procedure, you can define, as symbolic parameters, those parameters, 
subparameters and values that are likely to vary each time the procedure is used. For details 
on coding symbolic parameters, see the chapter "Using Symbolic Parameters." 
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Using Cataloged and In-Stream Procedures 

To use a cataloged or in-stream procedure, specify the procedure name on an EXEC statement. 
You can modify the procedure by adding DD statements, overriding, adding, or nullifying 
parameters on EXEC and DD statements, and assigning values to symbolic parameters. Calling 
and modifsdng procedures is explained in greater detail in the following paragraphs. 

How to Call Cataloged and In-Stream Procedures 

To call a cataloged or in-stream procedure, you identify the procedure on the EXEC statement 
of the step calling the procedure by coding as the first operand on the EXEC statement. 

• The procedure name. 

• PROC= the procedure name. 

A cataloged procedure must exist in the procedure library before you attempt to use it. JES2 
or JES3 is responsible for fetching cataloged procedures. Refer to "Routing a Job Through the 
System" to see how JES2 or JES3 determines what library to select. When using an in-stream 
procedure, include the procedure, beginning with a PROC statement and ending with a fend 
statement, with the job control language for the job; the procedure must follow the JOB 
statement but appear before the exec statement that calls it. You can include as many as 
fifteen uniquely named in-stream procedures in one job and can use each procedure as many 
times as you wish in the job. 

To call a cataloged procedure named PROCESSA, you would code: 

//CALL EXEC PROCESSA or 
//CALL EXEC PROC=PROCESSA 

On the EXEC statement, you can also code changes you would Uke to make for this 
execution of the procedure. 

Modifying Cataloged and In-Stream Procedures 

You can modify a procedure by: 

• Assigning values to or nullifying sjmibolic parameters contained in the procedure. 

• Overriding, adding, or nullif3dng parameters on EXEC and DD statements in the procedure. 

• Adding DD statements to the procedure. 

All changes you make are in effect only during the current execution of the procedure. For 
a discussion of symbolic parameters, see the chapter "Using S5mibolic Parameters." Other 
modifications are described in the following sections. 

Modifying Parameters on an EXEC Statement 

To override, add, or nullify a parameter on an EXEC statement in a procedure, identify on the 
EXEC statement that calls the procedure the parameter you are changing, the name of the 
EXEC statement on which the parameter appears, and the change to be made: 

//CALL EXEC procedurename, parameter .procstepname=value 

When overriding a parameter, the value coded for the parzmieter on the EXEC statement 
calling the procedure replaces the value assigned in the procedure. When adding a parameter, 
that parameter is used in the execution of the procedure step. When nullifjdng a parameter, 
you do not follow the equal sign with a value; the vzilue assigned to the parameter in the 
procedure is ignored. All changes made are in effect only for the current execution of the 
procedure. 
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You can make more than one change to each EXEC statement in the procedure, and you 
can change parameters on more than one EXEC statement in the procedure. You cannot, 
however, change the PGM parameter. When making changes on different steps in the 
procedure, code all changes for one procedure step before changes to a subsequent step. 

For example, the first three EXEC statements in a procedure named IRISH are: 

//STEP 1 EXEC PGM=YEATS , PARM= ' * 1 4863 ' 

//STEP2 EXEC PGM=NOLAN 

//STEP 3 EXEC PGM=SYNGE , TIME=( 2,30) 

and you want to make the following changes: 

• Nullify the FARM parameter in STEPl. 

• Add the COND parameter, specifying the test (8,LT), in STEP2. 

• Change the time limit in the TIME parameter in STEP3 to 4 minutes. 

On the EXEC statement calling the procedure, you would code: 

//CALL EXEC IRISH, PARM. STEPl =, 

// COND . STEP2=( 8 , LT ) , TIME . STEP3=4 

You can omit naming the procedure step when changing a parameter. When you do this, the 
procedure is modified as follows: 

• If the PARM parameter is coded, it applies only to the first procedure step. If a PARM 
parameter appears in a later exec statement in the called procedure, it is nullified. 

• If the TIME parameter is coded, it applies to the total procedure. If the TIME parameter 
appears on any of the EXEC statements in the called procedure, it is nullified. 

• If any other parameter is coded, it applies to every step in the called procedure. Nullifying 
the parameter on the EXEC statement calling the procedure causes the parameter to be 
ignored on every EXEC statement in the procedure; if you assign a value to the parameter 
on the EXEC statement calling the procedure, the parameter is overridden where it appears 
in the procedure and added to exec statements in the procedure on which it does not 
appear. 

For example, assume the EXEC statements in the procedure named COMPUTE are: 

//STEPl EXEC PGM=LIST,TIME=( 1 ,30) 
//STEP2 EXEC PGM=UPDATE,RD=NC,TIME=2 
//STEP3 EXEC PGM=CHECK,RD=RNC,COND=ONLY 

You want to make the following changes: 

1. Assign a time limit of 4 minutes to the entire procedure; time parameters on individual 
EXEC statements in the procedure wiU be nullified. 

2. Allow automatic step restart for each step of the job by coding rd=r. The rd 
parameter will be added to the first step of the job and will override the rd parameters 
in STEP2 and STEPS. 

To call the procedure and make these changes, you would code: 

//CALL EXEC COMPUTE , TIME=4 , RD=R 

During the processing of the JCL statements for the job, the EXEC statements appear as: 

//STEPl EXEC PGM=LIST,RD=R 

//STEP2 EXEC PGM=UPDATE,RD=R 

//STEP 3 EXEC PGM=CHECK , RD=R , COND=ONLY 
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Any parameter changes that affect every step of the job (by omitting the procedure step 
name) must be coded on the EXEC statement calUng the procedure before changes to 
parameters on different steps (that is, you include the procedure step name). Time will be a 
total of four minutes, each step using the remaining amount of time available from the total. If 
more than four minutes is required, the step will abnormally terminate. 

Modifying Parameters on a DD Statement 

To override, add, and nullify parameters on a DD statement in a procedure, you include a DD 
statement containing the changes you want to make after the EXEC statement that calls the 
procedure. The name of the DD statement containing the changes is composed of the 
procedure step name and the ddname of the DD statement in the procedure: 

//procstepname.ddname DD parameter=value 



When overriding a parameter, the value you code replaces the value assigned to the 
parameter in the procedure. When adding a parameter, the parameter is added to the DD 
statement in the procedure for the current execution of the procedure. When nuHifytng a 
parameter, you do not foUow the equal sign with a value; that parameter in the procedure is 
ignored. Do not nullify a parameter when you are replacing it with a mutually exclusive 
parameter; it wiU be nullified automatically. (See Figure 24 for a table of mutually exclusive 
parameters on the DD statement.) All changes you make are in effect only for the current 
execution of the procedure. 

You can change more than one parameter on a DD statement and you can change 
parameters on more than one DD statement in the procedure. However, the DD statements 
containing the changes must be coded in the same order as the corresponding DD statements in 
the procedure. Test all new procedures without overriding any parameters to ensure that the 
procedure statements are syntactically correct. 

For example, the first two steps of the cataloged procedure TEA are: 



//STEP1 
//DD1A 

// 

//DD1B 

//STEP2 

//DD2A 

// 



EXEC 
DD 

DD 

EXEC 

DD 



PGM=SUGAR 

DSNAME=DRINK , DISP= ( NEW , DELETE ) , 

UNIT=2400 , VOL=SER=568998 

UNIT=SYSSQ 



w.,^x-SYSSQ 
PGM=LEMON 



PGM=LEMON 

UNIT=2314,DISP=( , PASS ) , 
SPACE=(TRK,( 20,2) ) 



You want to make the following changes: 

1. Change the dispositon on the DD statement named DDlA to CATLG. 

2. Change the unit on the DD statement named DDIB to TAPE. 

3. Change the SPACE parameter on the DD statement named DD2A to SPACE=(CYL,(4,1)). 

When calling the procedure, you would code: 



//CALL EXEC 

//STEP1 .DD1A DD 

//STEP 1. DDIB DD 

//STEP2.DD2A DD 



TEA 

DISP=( NEW CATLG ) 

unit=tape' 
space=(cyl,(4, 1 ) ) 



When changing DCB subparameters, you need code only those subparameters you are 
changing. The DCB subparameters you do not code (and for which you do not code a mutually 
exclusive subparameter) remain unchanged. For example, a DD statement named DDl in a 
procedure step named STEPl contains DCB=(BUFNO=1,BLKSIZE=80,RECFM=F,BUFL=80). 
To change the block size to 320 and the buffer length to 320, you would code: 



//STEPl .DDl 



DD 



DCB=( BLKSIZE=320 , BUFL=320 
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The subparameters BUFNO and RECFM remain unchanged. 

To nullify the DCB parameter, you must nullify each subparameter. For example, if a DD 
statement in a procedure contains DCB=(RECFM=FB,BLKSIZE=160,LRECL=80), you must 
code DCB=(RECFM=,BLKSIZE=,LRECL=) in order to nullify the DCB parameter. 

To nullify the DUMMY parameter, code the DSNAME parameter on the overriding DD 
statement and assign a data set name other than NULLFILE. To nuUify all the parameters on a 
DD statement other than DCB, code DUMMY on the overriding DD statement. (The DUMMY 
parameter is described in detail in the chapter, "Defining a Dummy Data Set.") 

Modifying Parameters on DD Statements that Define Concatenated Data Sets 

When a concatenation of data sets is defined in a cataloged procedure and you attempt to 
override the concatenation with one DD statement, only the first (named) DD statement is 
overridden. To override others, you must include an overriding DD statement for each DD 
statement; the DD statements in the input stream must be in the same order as the DD 
statements in the procedure. The second and subsequent overriding statements must not be 
named. If you do not wish to change one of the concatenated DD statements, leave the 
operand field blank on the corresponding DD statement in the input stream. (This is the only 
case where a blank operand field for a DD statement is valid.) 

For example, suppose you are calling a procedure that includes the following sequence of 
DD statements in STEPC: 

DSNAME=A . B . C , DISP=OLD 

DSNAME=STRP , DISP=OLD , UNIT=23 1 4 , V0L=SER=X1 2 1 82 
DSNAME=TYPE3 , DISP=OLD , UNIT=23 1 4 , V0LUME=SER=BL1 42 1 
DSNAME=A . B . D , DISP=OLD 

To override the DD statements that define the data sets named STRP and A.B.D, you would 
code: 

//STEPC. DD4 DD 

// DD DSNAME=INV.CLS,DISP=OLD 

// DD 

// DD DSNAME=PAL8,DISP=OLD,UNIT=231 4, VOL=SER= 125688 

Adding DD Statements to a Procedure 

You can add DD statements to a procedure when calling the procedure. These additional DD 
statements are in effect only during the current execution of the procedure. 

To add a DD statement to a procedure step, follow the EXEC statement that calls the 
procedure and any overriding DD statements for that step with the additional DD statement. 
The ddname of the DD statement identifies the procedure step to which this statement is to be 
added and must be assigned a name that is different from all the ddnames in the procedure 
step. If you do not identify the procedure step in the ddname, the system assumes you are 
adding the DD statement to the first step of the procedure. 

For example, the first step of a cataloged procedure named MART is: 

//STEP1 EXEC PGM=DATE 

//DDM DD DSN=BPS(MEMG),DISP=OLD, 

// UNIT=23 1 4 , VOLUME=SER=554982 

//DDN DD UNIT=SYSSQ 



//DD4 


DD 


// 


DD 


// 


DD 


// 


DD 



I 
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You want to make the following changes: 

1. Change the UNIT parameter on the statement named DDN to UNIT=180. 

2. Add a DD statement, specifying UNIT=181. 

When calling the procedure, you would code: 



// EXEC 

//STEP 1 . DDN DD 
//STEP1 .DDO DD 



PROC=MART 

UNIT=180 

UNIT=181 



Identifying Procedure Statements on an Output Listing 

You can request that cataloged and in-stream procedure statements be included on the output 
listing by coding 1 as the first subparameter in the MSGLEVEL parameter on the JOB 
statement. (For a description of the MSGLEVEL parameter, see "Requesting Listings of JCL 
Statements and System Messages.") 

Procedure statements are identified on the output listing as illustrated in Figures 15 and 16. 
The output Usting will also show the symboUc parameters and the values assigned to them. 



Columns 




1,2,3 




XX 


cataloged procedure statement you did not override 


x/ 


cataloged procedure statement you did override 


XX* 


cataloged procedure statement, other than a comment 




statement, that the system considers to contain 




only comments 


*** 


comment statement, JES2, and JESS statements 



Figure 15. Identification of Cataloged Procedure Statements on the Output Listing 



Columns 
1 2 3 



++ 

+/ 

++* 



in-stream procedure statement you did not override 

in-stream procedure statement you did override 

in-stream procedure statement, other than a comment 

statement, that the system considers to contain only 

comments 

comment statement, JES2, and JES3 statements 



Figure 16. Identification of In-stream Procedure Statements on the Output Listing 



Using Symbolic Parameters 



In order to be modified easily, cataloged and in-stream procedures can contain symbolic 
parameters. A symbolic parameter is a symbol preceded by an ampersand that stands for a 
parameter, a subparameter, or a value. In the following procedure step, the symboUc 
parameters are underlined: 

PGM=UPDATE , ACCT= ( PGMG , SDEPT ) 

DSNAME=INIT , UNIT^ &DEVICE , SPACE=( CYL , ( SSPACE , 10 ) ) 

DSNAME=CHNG, UNIT=2400 , DCB=BLKSIZE=SLENGTH 



//STEP1 


EXEC 


//DD1 


DD 


//DD2 


DD 
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When this procedure is executed, every symbolic parameter must either be assigned a value 
or nullified; the changes are in effect only for the current execution of the procedure. ■ 

Therefore, the procedure can be modified each time it is executed, without being permanently 
changed. Details on how to assign values to or nullify symbolic parameters are included under 
"Assigning Values to and Nullifying Symbolic Parameters." How to include symbolic 
parameters when writing a cataloged or in-stream procedure is described in the next section, 
"Defining Symbolic Parameters When Writing a Procedure." 

Defining Symbolic Parameters When Writing a Procedure 

Any parameter, subparameter, or value in a procedure that can vary each time the procedure is 
called is a good candidate for definition as a symbolic parameter. For example, if different 
values can be passed to a processing program by means of the FARM parameter on one of the 
EXEC statements, you could define the FARM field as one or more symbolic parameters, for 
example, farm=&allvals or farm =& deck «fe code. 

The symbolic parameter itself is one to seven alphameric and national (#,@,$) characters 
preceded by a single ampersand. The first character must be alphabetic or national. Since a 
single ampersand defines a symbolic parameter, you code double ampersands when not 
defining a symbolic parameter. For example, if you want to pass 543 & LEV to a processing 
program by means of the FARM parameter, you must code FARM='543&&LEV'. The system 
treats the double ampersand as if a single ampersand had been coded, and only one ampersand 
appears in the results. 

Keyword parameters that can be coded on the EXEC statement (such as ACCT, COND, and 
farm) cannot be used as the name of a symbolic parameter. For example, you cannot code 
&REGION=200K or REGlON=& REGION on the EXEC statement, but you can code 
REGION=&SIZE. 



The definitions used to signify symbolic parameters should be consistent in all the cataloged 
and in-stream procedures at an installation. For example, every time the programmer is to 
assign his department number to a symbolic parameter, no matter which procedure he is 
calling, the symbolic parameter could be defined as &DEFT. In different procedures, you could 
code ACCT=(43877,«&DEPT) and DSNAME=LIBRARY.&DEFT.TALLY. The programmer would 
assign his department number to the symbolic parameter wherever that symbolic parameter 
appears in a procedure. 

The same symbolic parameter can appear more than once in a procedure, as long as the 
value assigned to the symbolic parameter is a constant in the procedure. Therefore, you could 
use & DEFT more than once in a procedure, if the department number to be assigned is the 
same in each use. But if you have two DD statements and include a symboHc parameter for the 
primary quantity of the space request on each DD statement, you would not want to use the 
same symbolic parameter, since the requests for primary quantity could be different for the 
two data sets. Only one value can be assigned to each symbolic parameter used in a procedure; 
if you assign more than one value to a symboUc parameter, only the first value is used and 
that value is substituted wherever the symbolic parameter occurs. 

Assigning Default Values to Symbolic Parameters 

You can assign default values to the symbolic parameters coded in the procedure on the FROC 
statement. The FROC statement must always appear as the first statement in an in-stream 
procedure; the FROC statement must be coded as the first statement in a cataloged procedure 
only if you want to assign defaults. Generally, you should assign defaults to every symboUc 
parameter in a procedure to limit the amount of coding necessary each time the procedure is 
called. See the next section, "Assigning Values to and Nullifying Symbolic Parameters", for 
details. 
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Assigning Values to and Nullifying Symbolic Parameters 

When a procedure containing symbolic parameters is used, each symbolic parameter must 
either be assigned a value or nullified. Symbolic parameters are assigned values or nullified in 
one of two ways: 

• the programmer who uses the procedure codes the symbolic parameter on the EXEC 
statement calling the procedure, either assigning it a value or nullifying it; 

• the programmer who writes the procedure assigns a default value to or nullifies the symbolic 
parameter on the PROC statement, which must be the first statement in an in-stream 
procedure and can be the first statement in a cataloged procedure. 

The default assigned to a symbolic parameter on a PROC statement is overridden when that 
symbolic parameter is assigned a value or nullified on the EXEC statement that calls the 
procedure. 

Default values are not necessarily assigned to S5mibolic parameters in a procedure. Before 
using any procedure, find out what symbolic parameters are used, the meaning of each 
symbolic parameter, and what default, if any, is assigned. The PROC statement is optional in 
cataloged procedures; if the PROC statement is not included, no default values can be assigned 
to symbolic parameters in the procedure. 

You need not code the symbolic parameters in any specific order when you assign values to 
or nullify them. 

Assigning a Value to a Symbolic Parameter 

To assign a value to symbolic parameter, you code: 

symbolic parameter=value 

Omit the ampersand that precedes the S)n3ibolic parameter in the procedure. For example, if 
the symbolic parameter & NUMBER appears on a DD statement in the procedure, code 
NUMBER=value on the PROC statement (if you are writing the procedure and assigning 
defaults) or on the EXEC statement that calls the procedure (if you are using the procedure 
and want this value to be in effect only for the current execution of the procedure). 

There are some rules for assigning values to symbolic parameters: 

• The length of the value assigned is limited only in that the value cannot be continued onto 
another statement. However, when a sjmibolic parameter is concatenated with other 
information (for example, a data set name is LIBRARY. &DEPT.. MACS), the combined length 
of the value you assign and the concatenated information cannot exceed 120 characters. 

• If the value contains special characters, enclose the value in apostrophes (the enclosing 
apostrophes are not considered part of the value). If the special characters include 
apostrophes, each apostrophe must be shown as two consecutive apostrophes. 

• If more than one value is assigned to a symbolic parameter as a default on the PROC 
statement, only the first value encountered is used; likewise, if more than one value is 
assigned to a symbolic parameter on an EXEC statement, only the first value encountered is 
used. 

• If a symbolic parameter is a positional parameter followed by other parameters in the 
statement, it should be followed in the procedure by a period instead of a comma; for 
example: 

//DEFINE DD gPOSPARM.DSN=ATLAS ,DISP=OLD 



Cataloged and In-Stream Procedures 125 



• A value of literal blanks, that is, VALUE=' ', should not be used to nullify a symbolic 
parameter. 

Symbolic parameters that are ke5rword subparameters should appear in the procedure 
without a preceding comma; for example: 

VOLUME=SER=( 111111 &SERNO ) 

This is necessary so that, if the symbolic parameter is nullified, a leading or trailing comma 
will not cause a JCL syntax error. (For a more complete discussion of this, see "Caution 
Concerning Leading and Trailing Commas.") 

In these cases, you must include a comma when you assign a value to the symbolic 
parameter; that is: 

POSPARM= ' DUMMY , ' 
SERNO=' ,222222' 

Since the comma is a special character, the value must then be enclosed in apostrophes. 

Nullifying a Symbolic Parameter 

To nullify a symbolic parameter, code: 

symbolic parameter= 

Omit the ampersand that precedes the symbolic parameter in the procedure and do not 
follow the equal sign with a value. 

For example, a DD statement in an in-stream procedure named TIMES is: 

//DD8 DD UNIT=321 1 ,UCS=£UCSINFO 

If you are writing the procedure and want to nullify &UCSINFO as a default on the PROG 
statement, code: 

//TIMES PROC UCSINFO= 

If you are calling the procedure, and no default was assigned to &UCSINFO, or if 
ifeUCSlNFO was assigned a value on the PROC statement, nullify the parameter on the EXEC 
statement that calls the procedure by coding: 

//CALL EXEC TIMES, UCSINFO= 

Caution Concerning Leading and Trailing Commas 

All symbolic parameters must be assigned values or nullified before the procedure is executed. 
(When you write a procedure, you can assign default values to the symbolic parameters, or the 
programmer can assign values when he calls the procedure; for details, see "Assigning Values 
to and Nullifying Symbolic Parameters.") When a symbolic parameter is nullified, a delimiter, 
such as a leading or trailing comma, is not automatically removed. Only when the symbolic 
parameter is a positional subparameter followed by other subparameters should the comma 
remain. In other cases, the remaining comma will cause a syntax error. 

For example, you code for a unit request: 

UNIT=( 2314, &MORE , DEFER ) 



f 
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If &MORE is nullified, the comma before it must remain, since the unit count subparameter 
is positional and a comma must indicate its absence if other subparameters follow. When 
&MORE is nullified, the parameter will appear as: 

UNIT=( 2314, , DEFER) 

However, if you code: 

VOLUME=SER=( 111111, SSERNO ) 

and &SERNO is nullified, a leading comma will remain and cause a JCL syntax error. If a 
symboUc parameter is a positional parameter followed by other parameters in the statement, 
such as 

//DEFINE DD £POSPARM,DSN=ATLAS ,DISP=OLD 

the comma will remain at the beginning of the operand field if &POSPARM is nullified and 
again cause a syntax error. 

In these cases, you should not code the comma. When a symboUc parameter follows 
information that does not vary, such as in VOLUME=SER=(llllll,&SERNO), you do not have 
to code any delimiter. The system recognizes the symbolic parameter when it encounters the 
single ampersand. For this example, you would code: 

VOLUME=SER=( 111111 SSERNO ) 

When a value is assigned to the symboUc parameter, a comma must be included in the 
value, that is, SERNO= ',222222'. (Since the comma is a special character, the value is enclosed 
in single apostrophes.) 

When a symbolic parameter precedes information that does not vary, a period may be 
required after the symbolic parameter to distinguish the end of the symbolic parameter from 
the beginning of the information that does not vary. A period is required after the symboUc 
parameter when the character foUowing the symboUc parameter is: 

• An alphabetic, numeric, or national (#,(§),$) character. 

• A left parenthesis or a period. 

The system recognizes the period as a delimiter and the period does not appear in the 
procedure after the symboUc parameter is assigned a value or nulUfied. (A period will appear 
after the value when two consecutive periods are coded.) 

Therefore, you should place a period after a symboUc parameter that stands for a positional 
parameter followed by other parameters in the statement: 

//DEFINE DD SPOSPARM.DSN=ATLAS ,DISP=OLD 

If &POSPARM is nullified, the statement appears as: 

//DEFINE DD DSN=ATLAS , DISP=OLD 

When assigning a value to & POSPARM, you must include a comma: 

POSPARM= ' DUMMY , ' 

These rules are in effect whenever you are concatenating a symboUc parameter with 
information that does not vary. In the foUowing examples, a symboUc parameter is placed after 
information that does not vary. 
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I In these examples, the system recognizes the symbolic parameter when it encounters the & : 

• DSNAME=LIBRARY( & MEMBER) 

• DSNAME=USERLIB.«&LEVEL 

In the following examples, a symbolic parameter is placed before information that does not 
vary: 

• PARM='&0PTI0N+15'. &OPTION is not followed by period because of the +. 

• DSNAME=&QUAL.246. The period is required because a numeric character follows the 
symbohc parameter. 

• DSNAME=& LIBRARY. (MEMG). The period is required because a left parenthesis follows the 
symbolic parameter. 

• DSNAME=&DOCNO..TXT. The period is required because a period follows the symbohc 
parameter. A single period will appear in the results. 

You can also define two or more symbohc parameters in succession without including a 
comma, for example, PARM=&DECK&CODE. If a comma is desired m the results, a comma 
must then be included in the value assigned to the sjmiboUc parameter. 

Example of a Procedure Containing Symbolic Parameters 

The cataloged procedure named TESTPROC contains the following statements: 

//TESTPROC PROC A=IMB406 ,B=ABLE,C=3330 ,D=WXYZ1 , 

// E=OLD,F=TRK,G=' 10, 10, 1 • 

//STEP EXEC PGM=SA 

//DD1 DD DSN=&B,UNIT=&C,VOL=SER=&D,DISP=SE, 

// SPACE=( £F,( SG) ) 

To execute the above cataloged procedure with certain overrides (change DSN to BAKER, 
PGM to IEFBR14, DISP to (NEW, KEEP), and leave the remainder of the parameters the same), 
code the following statements: 

//TESTJOB JOB , ,MSGLEVEL=( 1 , 1 ) ,PERFORM=25 

//STEPX EXEC TESTPROC, A=IEFBR14,B=BAKER,E=( NEW, KEEP) 

After the symbohc substitution, the statements will look like the following: 

//STEP EXEC PGM=IEFBR14 

//DD1 DD DSN=BAKER,UNIT=3330,VOL=SER=WXYZ1, 

// DISP= (NEW, KEEP ),SPACE=(TRK,{ 10,10,1 ) ) 

To execute the above cataloged procedure and change DDl to resemble a temporary scratch 
space. 

//TESTJOB JOB , ,MSGLEVEL=( 1 , 1 ) ,PERFORM=25 
//STEPX EXEC TESTPROC,A=IEFBR14,B=,C=2314,D=,E= 

After the symbolic substitution, the statements will look hke the following: 

//STEP EXEC PGM=IEFBR14 

//DDl DD DSN=, UNIT=231 4, VOL=SER=,DISP=,SPACE=(TRK,( 10,10,1 ) ) 
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There are certain rules common to all parameters. Syntax rules define how to code each 
parameter; that is, what is required or optional for the specific purpose or process you are 
requesting. Certain fields on the control statements are common to most parameters, such as, 
the name field, the operation field, and the operand field. Special characters can be coded on 
the parameters if you follow guidelines established in the rules for coding. 

Notation for Defining Control Statement Parameters 

The formats of the parameters described in this publication for the JOB, EXEC, DD, JES2, and 
JES3 statements appear at the beginning of the chapter on the corresponding parameter. 
Notations used in the format descriptions are described below. 

1. Uppercase letters and words are coded on the control statement exactly as they appear 
in the format description, as well as the following characters: 

ampersand & 

asterisk * 

comma , 

equal sign = 

parenthesis () 
period 

2. Lowercase letters, words, and symbols appearing in the format description represent 
variables for which specific information is substituted when the parameter is coded. 

For example, CLASS =jobclass is the format description for the CLASS parameter. When 

I you code the CLASS parameter on a JOB statement, you substitute an alphameric 
character for the word "jobclass" . 

3. Braces {} are a special notation and are never coded on a control statement. Braces are 
used to group related items; they indicate that you must code one of the items. 

For example, I TRK f is part of the format description for the SPACE parameter. 
JCYL [ 
(block size) 

When coding the SPACE parameter, you must code either TRK, CYL, or a substitute for 
"block size", which would be a number. 

4. Brackets [] are a special notation and are never coded on a control statement. Brackets 
indicate that the enclosed item or items are optional and you can code one or none of 
the items. 

For example, [,DEFER] is part of the format description for the UNIT parameter. When 
you code the UNIT parameter, you can include ,DEFER in the UNIT parameter or omit it. 

An example of more than one item enclosed in brackets is 

rEXPDT=yyddd1 
LRETPD=nnnn J 

which is part of the format description for the LABEL parameter. When coding the LABEL 
parameter, you can include either EXPDT=yyddd or RETPD=nnnn in the LABEL 
parameter or omit both. 
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Sometimes, one of a group of items enclosed in brackets is a comma. Code the comma 
when none of the other items in the group is used and a following part of the parameter 
is still to be coded. 



For example, 



r,progname~| 



[.form name] 



is part of the fonnat description for the SYSOUT parameter. When you code the SYSOUT 
parameter, you have the option of coding both "progname" and ",form name", omitting 
both, or coding only one. The comma enclosed in brackets with ",progname" must be 
coded when ",progname" is not coded but ",form name" is coded; that is, you would 
code: „form name. 

5. An ellipsis... (three consecutive periods) is a special notation and is never coded on a 
control statement. An ellipsis is used to indicate that the preceding item can be coded 
more than once in succession. 

For example, COND=((code,operator),...) is the format description for the COND 
parameter on the JOB statement. The ellipsis indicates that (code,operator) can be 
repeated. 

6. Two consecutive periods (..) are used to concatenate symbolic parameters to other 
information. For example, &DEPT..MACS is the symbolic parameter. &DEPT=D58. 
Therefore, the actual value is D58.MACS. 

Fields in JCL Control Statements 

Every control statement is logically divided into different fields. There are four fields — name 
field, operation field, operand field, comments field — but not all of the control statements 
can contain all of these fields. Figure 17 shows the fields for each statement. 



Statement 


Columns 1 and 2 


Fields 


JOB 

EXEC 

DD 

PROC (cataloged) 

PROC (in -stream) 

PEND 

Command 

Delimiter 

Null 


// 
// 
// 
// 
// 
// 
// 
/* 
// 


name operation ( JOB ) operand comments ^ 
name' operation (EXEC) operand comments^ 
name' operation ( DD ) operand comments'^ 
namel operation ( PROC ) operand comments^ 
name operation ( PROC ) operand ' comments ^ 
name' operation (PEND) comments^ 
operation (command) operand comments^ 
comments' 


Statement 


Columns 1,2,3 


Field 


Comment 


//* 


comments 


^ Optional 

Optional — If operand(s) are not coded, comments cannot be coded. 
If operand(s) are coded, comments are optional. 



Figure 17. JCL Control Statement Fields 

The name field identifies the control statement so that other statements and system control 
blocks can refer to it. The name field is 1 to 8 alphameric and national (#,@,$) characters; 
the first character must be alphabetic or national. The name field must begin in colimm 3. 
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The operation field specifies the type of control statement, or, in the case of the command 
statement, the command. The operation field must follow the name field and must be preceded 
and followed by at least one blank. 

The operand field contains parameters separated by commas. The operand field must follow 
the operation field and must be preceded and followed by at least one blank. The operand 
field is described in more detail in the next chapter "Parameters in the Operand Field." 

The comments field contains any information deemed helpful by the person who codes the 
control statement. The comments field must follow the operand field and must be preceded by 
at least one blank. The operand field can be continued; it does not have to be completed 
before you add the comments field. 

Control statement fields — except the name field, which must begin in column 3 — can be 
coded in free form. Free form means that the fields need not begin in a particular column. 
Separate each field with a blank; the blank serves as a delimiter between fields. 

Except for the comment statement, which can be coded through column 80, fields cannot be 
coded past column 71. If the total length of the fields will exceed 71 columns, you must 
continue the fields onto one or more succeeding statements. How to continue fields is 
described under "Continuing Control Statements." 

Parameters in the Operand Field 

The operand field is made up of two types of parameters: one type is characterized by its 
position in the operand field in relation to other parameters (a positional parameter); the other 
type is positionally independent with respect to others of its type, and is characterized by a 
ke3rword followed by an equal sign and variable information (a ke5rword parameter). Both 
positional parameters and the variable information associated with kejrword parameters can 
assume the form of a Ust of several items (subparameters) of information. 

All positional and keyword parameters and subparameters coded in the operand field must 
be separated from one another by commas. 

Positional parameters must be coded first in the operand field in a specific order. The absence 
of a positional parameter is indicated by a comma coded in its place. However, if the absent 
parameter is the last one, or if all later positional parameters are also absent, you need not 
code replacing commas. If all positional parameters are absent from the operand field, you 
need not code any replacing commas. 

Keyword parameters can be used anjrwhere in the operand field with respect to one another. 
Because of this positional independence, you need not indicate the absence of a ke5rword 
parameter. 

A positional parameter or the variable information in a keyword parameter sometimes 
assumes the form of a list of subparameters. Such a list may be composed of both positional 
and kejrword subparameters that follow the same rules and restrictions as positional and 
kejrword parameters. You must enclose a subparameter list in parentheses, unless the Ust 
reduces to a single subparameter. 

The EXEC statements and DD statements in cataloged procedures can contain one other 
type of parameter — a symbolic parameter. A symbolic parameter is characterized by a name 
preceded by an ampersand ( & ); a symbolic parameter stands as a symbol for a parameter, a 
subparameter, or a value. Symbolic parameters allow you to make any information in the 
operand field of a procedure EXEC statement or DD statement variable. A value to be assumed 
by a symbolic parameter may be coded on the EXEC statement that calls the procedure. This 
value is in effect only while the procedure is being executed. For a detailed discussion on how 
to use symbolic parameters in a set of control statements that you plan to catalog as a 
procedure, refer to the section "Using SymboUc Parameters." 
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Continuing Control Statements | 

When the total length of the fields on a control statement will exceed 71 columns, you must 
continue the fields onto one or more succeeding statements. 

The command, comment, delimiter, and null statements cannot be continued. 

You can continue the operand field or the comments field of other JCL statements. To 
continue either of these fields, you must follow the continuation conventions. 

To continue the operand Held: 

1. Interrupt the field after a complete parameter or subparameter, including the comma that 
follows it, at or before column 71. 

2. Comments can be included by following the interrupted field with at least one blank. 

3. Code a nonblank character in column 72 when you are continuing a comments field. 
Optionally, code any nonblank character in column 72 for all other continued 
statements. If you do not code a character in column 72 when continuing the operand 
field, the system treats the next statement as a continuation statement as long as you 
follow the conventions outUned in items 4, 5, and 6. 

4. Code the identifying characters // in columns 1 and 2 of the following statement. 

5. Continue the interrupted operand beginning in any column from 4 through 16. If you 
begin coding after column 16, the system assumes that no other operands are present 
and treats any characters you code as a comment field. 

6. If there is a nonblank in column 3, the system assumes that this is a new statement. The 
job fails and an error message is issued saying no continuation is found. 

To continue the comments field: 

1. Interrupt the comment at a convenient place before column 72. 

2. Code a nonblank character in column 72. 

3. Code the identifjdng characters // in columns 1 and 2 of the following statement. 

4. Continue the comments field beginning in any column after column 3. 

Any control statements in the input stream, other than a comment statement, that the 
system considers to contain only comments have //* in columns 1 through 3 on an output 
hsting. Any control statements in a cataloged procedure, other than a comment statement, that 
the system considers to contain only comments have XX* in columns 1 through 3 on an 
output listing. For a comment statement, *** appears in columns 1 through 3 on an output 
listing. Any control statements in an instream procedure show + + in columns 1 and 2 of an 
output listing. 
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Character Sets 



Job control statements are coded using a combination of the characters from three different 
character sets. The contents of each of the character sets are described in Figure 18. 



Character Set 


Contents 


Alphameric 


Alphabetic 
Numeric 


A through Z 
through 9 


National 


"At " sign 
Dollar sign 
Pound sign 


@ 

s 
# 


Special 


Comma 

Period 

Slash 

Apostrophe 

Left parenthesis 

Right parenthesis 

Asterisk 

Ampersand 

Plus sign 

Hyphen 

Equal sign 

Blank 


/ 

1 

( 
) 

* 

& 

+ 



Figure 18. Character Sets 

When coding any special characters, certain rules must be followed. These rules and the use 
of special characters are described next. 

Using Special Characters 

Special characters are used in the job control language to: 

1. Delimit parameters (the comma). 

2. Delimit fields (the blank). 

3. Perform syntactical functions. (For example, the appearance of && as the first two 
characters following DSNAME= tells the system that a temporary data set name follows.) 

Sometimes you can code a special character that does not satisfy one of the three uses of 
special characters. In most of these cases, indicate that special characters are being used by 
enclosing the item that contains the special characters in apostrophes (5-8 punch), for 
example, ACCT='123+456'. If one of the special characters is an apostrophe, you must code 
two consecutive apostrophes (two 5-8 punches) in its place, for example, 'O'NEILL'. 

The following list contains those parameters that can have special characters as part of their 
variable information, and indicates when the apostrophes are not required. 

1. The accounting information on the JOB statement. The account number and additional 
accounting information can contain hyphens without being enclosed in apostrophes. 

2. The programmer's name on the JOB statement. The programmer's name can contain 
periods without being enclosed in apostrophes. 

3. The checkid field in the RESTART parameter on the JOB statement may contain an *. 
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4. The ACCT parameter on the EXEC statement. The ACCT parameter can contain hyphens 
and plus zero without being enclosed in apostrophes. 

5. The FARM parameter on the EXEC statement may contain an ampersand for symbolic 
parameters. When the ampersand is used in that way, apostrophes are not required. 

6. The DSNAME parameter on the DD statement. The DSNAME parameter can contain 
hyphens without being enclosed in apostrophes. If the DSNAME parameter contains a 
qualified name, it can contain periods without being enclosed in apostrophes. If the DD 
statement identifies a generation of a generation data group, the generation number in 
the DSNAME parameter can contain a plus or minus (hyphen) sign without being 
enclosed in apostrophes. If the DD statement defines a temporary data set, the DSNAME 
parameter can contain, as the first two characters, ampersands without being enclosed in 
apostrophes. If the DD statement defines a member of a partitioned data set, a 
generation of a generation data group, or an area of an indexed sequential data set, the 
DSNAME parameter contains parentheses that enclose the member name, generation 
number, or area name; these parentheses are not enclosed in apostrophes. 

7. The volume serial number in the VOLUME parameter on the DD statement. The volume 
serial number can contain hyphens without being enclosed in apostrophes. 



( 
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The JOB Statement 



^^ 



Control Statement 



The JOB statement marks the beginning of a job and, when jobs are stacked in the input 
stream, marks the end of the control statements for the preceding job. 

{ //jobname JOB operands comments 

The JOB statement consist of the characters //in columns 1 and 2, and four fields — the 
name, operation (JOB), operands, and comments fields. 



General Rules for Coding 



• Code a JOB statement for each job. Code a unique jobname in every JOB statement. The 
jobname must consist of 1 through 8 alphameric and national (#,@,$) characters; the first 
character must be alphabetic or national. 

• The two types of parameters that can be coded on the JOB statement are: 

Positional parameters, which must precede any keyword parameters and must be coded in the 
following order. 

accounting information 
programmer's name 

Keyword paratmters, which can be coded in any order after the positional parameters. Any of 
the following keyword parameters can be coded on the JOB statement. 

ADDRSPC 

CLASS 

COND 

GROUP 

MSGCLASS 

MSGLEVEL 

NOTIFY 

PASSWORD 

PERFORM 

PRTY 

RD 

REGION 

RESTART 

TIME 

TYPRUN 

USER 

• All parameters in the operand field are optional unless the account number and 
programmer's name parameters are required by the installation. 

• If you code no parameters in the operand field of the JOB statement, code no comments. 



Sample JOB Statements 



//ALPHA 


JOB 


//LOS 


JOB 


//MART 


JOB 


//TRY 8 


JOB 


//RACE 1 


JOB 



843,LINLEE,CLASS=F,MSGLEVEL=( 1,1 ) 
,BROWNLY,TIME=(4,30 ), MSGLEVEL- ( 2,0 ) 
1 863 , RESTART=STEP4 

'D83, 123' ,USER=RAC01 ,GROUP=MYGROUP, PASSWORD=XYY 
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The Accounting Information Parameter— /^osiViowa/, optional (according to 
installation procedures) 



The accounting information parameter identifies an account number and any information that 
may be required by the installation. 

For information on how to add accounting facilities, refer to OS/VS System Management 
Facilities (SMF). 



( [account number] [, additional accounting information,...] 



General Rules for Coding 



• This field may also contain JES2 parameters similar to those on the JOBPARM control 
statement to maintain compatability with HASP. 

• When accounting information consists of more than one item, enclose the information in 
either parentheses or apostrophes, for example, (5438,GROUP6) or '5438,GR0UP6'. If you 
use apostrophes, all accounting information enclosed in the apostrophes in considered as one 
field. 

• If you code an ampersand or an apostrophe as part of the accounting information, you must 
code them as double characters. For example, '2570" AB'. 

• The account number and other accounting information must not exceed 142 characters in 
total, including the commas that separate the items. 

• If you must continue the accounting information on another statement, enclose the j 
information in parentheses. ^ 

Special Characters 

• If any of the included items contain special characters (except hyphens), either: 
— Enclose the accounting information in apostrophes. 

— Enclose the item in apostrophes and the accounting information in parentheses. The 
enclosing apostrophes are not considered part of the information. If an apostrophe is part of 
the data, code two consecutive apostrophes. 

• If one of the special characters is an ampersand or apostrophe and you are not defining a 
symbolic parameter, code two consecutive ampersands or apostrophes in its place. 

Examples of the Accounting Information Parameter 

//JOB43 JOB D548-8686 

//J0B44 JOB (D548-8686, ' 12/8/73' ,ERICKSON) 

Accounting number plus additional information; parentheses are required. 
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The JOB Statement 




Control Statement 



The JOB statement marks the beginning of a job and, when jobs are stacked in the input 
stream, marks the end of the control statements for the preceding job. 



r 



//jobname JOB operands comments 



The JOB statement consist of the characters //in columns 1 and 2, and four fields — the 
name, operation (JOB), operands, and comments fields. 



General Rules for Coding 



• Code a JOB statement for each job. Code a unique jobname in every JOB statement. The 
jobname must consist of 1 through 8 alphameric and national (#,@,$) characters; the first 
character must be alphabetic or national. 

• The two types of parameters that can be coded on the JOB statement are: 

Positional parameters, which must precede any keyword parameters and must be coded in the 
following order. 

accounting information 
programmer's name 

Keyword parameters, which can be coded in any order after the positional parameters. Any of 
the following keyword parameters can be coded on the JOB statement. 

ADDRSPC 

CLASS 

COND 

MSGCLASS 

MSGLEVEL 

NOTIFY 

PERFORM 

PRTY 

RD 

REGION 

RESTART 

TIME 

TYPRUN 

• All parameters in the operand field are optional unless the account number and 
programmer's name parameters are required by the installation. 

• If you code no parameters in the operand field of the JOB statement, code no comments. 



Sample JOB Statements 



//ALPHA 


JOB 


//LOS 


JOB 


//MART 


JOB 


//TRY8 


JOB 



843,LINLEE,CLASS=F,MSGLEVEL=( 1,1) 
, BROWNLY , TIME=( 4,30), MSGLEVEL=( 2 , 
1863, RESTART=STEP4 
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The Accounting Information Parameter — positional, optional (according to 
installation procedures) 



The accounting information parameter identifies an account number and any information that 
may be required by the installation. 

For information on how to add accounting facilities, refer to OS/VS2 System Programming 
Library: System Management Facilities (SMF). 

f (account number! [ , additional accounting information, . . . ] ) 

JES2 Parameters 

The accounting information parameter may contain JES2 parameters similar to those on the 
JOBPARM control statement to maintain compatibility with JES2. JES2 considers this account 
field valid if its format is that specified for JES2. The format is assumed to be as follows: 

( pano , room, t ime, 1 ines , cards , forms , copies , log , 1 meet ) 

pano 

programmer's accounting number, one to four alphameric characters. 
room 

programmer's room number, one to four alphameric characters. 
time 

estimated execution time in minutes, up to four numeric digits (for example, ",30" for 30 

minutes). If omitted, a standard value is assumed. 
lines 

estimated line count in thousands of lines, up to four numeric digits (for example, ",5" for 

5000 lines). If omitted, a standard number of lines is assumed. 
cards 

estimated number of cards to be punched, up to four numeric digits. If omitted, a standard 

number of cards is assumed. 
forms 

special forms for printing an entire job, from one to four alphameric characters (for 

example, ",5" for five-part forms). If omitted, standard forms are assumed. 
copies 

number of times output is to be printed or punched, up to three numeric digits not 

exceeding an installation-specified limit (maximum 255) (for example, ",2" for two copies). 

If omitted, one copy is assumed. 
log 

Job Log option. This subfield should consist of one character. If this character is an "N", 

the JES2 Job Log is not produced. If any other character or if omitted, the log is produced 

unless NOLOG was specified for that job class during initialization. 
linect 

lines to be printed per page, up to three numeric digits not exceeding 255. If coded as zero, 

no automatic overflow is produced. If omitted, a standard value is assumed. 

Note: If JES2 has been initialized to terminate a job that has an accounting field subparameter 
that is illegal by JES2 standards, then the first two subfields (pano and room) are required. 



i 
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For a discussion of the JES2 scan of the accounting information field, refer to OS/VS2 MVS 
System Programming Library: JES2. 




General Rules for Coding 



acct info 



I 



• When accounting information consists of more than one item, enclose the information in 
either parentheses or apostrophes, for example, (5438,GROUP6) or '5438,GR0UP6'. If you 
use apostrophes, all accounting information enclosed in the apostrophes in considered as one 
field. 

• If you code an ampersand or an apostrophe as part of the accounting information, you must 
code them as double characters. For example, '2570"AB'. 

• The account number and other accounting information must not exceed 142 characters in 
total, including the commas that separate the items. 

• If you must continue the accounting information on another statement, enclose the 
information in parentheses. 

Special Characters 

• If any of the included items contain special characters (except hyphens), either: 
— Enclose the accounting information in apostrophes. 

— Enclose the item in apostrophes and the accounting information in parentheses. The 
enclosing apostrophes are not considered part of the information. If an apostrophe is part of 
the data, code two consecutive apostrophes. 

• If one of the special characters is an ampersand or apostrophe and you are not defining a 
symbolic parameter, code two consecutive ampersands or apostrophes in its place. 

Examples of the Accounting Information Parameter 

//JOB43 JOB D548-8686 

//J0B44 JOB (D548-8686, ' 12/8/73' ,ERICKSON) 

Accounting number plus additional information; parentheses are required. 
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The ADDRSPC Parameter— keyword, optional 



The ADDRSPC parameter indicates whether or not the job can be paged. 

For further information on the ADDRSPC parameter, see the section "Requesting Storage 
For Execution of a Program." 







acct info 
ADDRSPC 



ADDRSPC= 



S VIRT I 
\ REAL \ 



VIRT 

a keyword indicating that the job can be paged. 
REAL 

a ke5nvord indicating that the job cannot be paged. 

Default: If you omit the ADDRSPC parameter, the default is VIRT, unless the installation has 
changed the default. 

General Rules for Coding 

• The ADDRSPC parameter coded on a JOB statement will override any ADDRSPC parameter 
coded on an EXEC statement for that job. 

• Requests for real and virtual storage can be made in the same job. Each step will honor the 
request for either real or virtual storage if there is no ADDRSPC parameter on the JOB 
statement. 

Rule for Coding when Using Real Storage 

I Code the region parameter to specify how much real storage is needed, or allow it to default. 

Rule for Coding when Using Virtual Storage 

The installation provides a default region size for use when the REGION parameter is not 
specified when ADDRSPC=VIRT is coded or implied. That value, or the value specified on the 
REGION parameter if coded, sets the upper boundary to limit region size for variable-length 
GETMAlNs as long as there remains in the region at least the minimum amount of storage 
requested. In addition, the region value is used by an IBM or installation-supplied routine 
(iealimit) to estabUsh a second value used to limit fixed-length GETMAlNs, and 
variable-length GETMAlNs when the space remaining in the region is less than the requested 
minimum. When the minimum requested length for variable-length GETMAlNs causes this 
second value to be exceeded, the job or job step abnormally terminates. For further 
information, see OS/VS2 System Programmii^ Library; Job Management. 

Examples of the ADDRSPC Parameter 

//PEH JOB , BAKER, ADDRSPC=VIRT 

The ADDRSPC parameter requests virtual storage. The area size available to the user is the 
installation-supplied default, since a value is not specified on the REGION parameter. 

//DEB JOB ERIC,ADDRSPC=REAL,REGION=100K 

The ADDRSPC parameter requests real storage. The REGION parameter specifies the amount; in 
this case, lOOK. 
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The CLASS Psffwneter-— keyword, optional i 



The CLASS parameter assigns a job class to each job, depending on the characteristics of the 
job and the installation's rules for assigning a job class. 

For further information on the use of the CLASS parameter, see "Assigning a Job to a Job 
Class." 

CLASS=jobclass 

jobclass 

any character A-Z or 0-9, defined by the installation. 

Default: Determined by the source of the job; that is, the particular card reader or work 
station, or whether the job was submitted by a time-sharing user. JES2 and JES3 use the 
installation-defined default. 

Rule for Coding 

When coding JES3, a valid CLASS parameter on the JES3 MAIN statement overrides a valid 
CLASS parameter on the JOB statement. 

Example of the CLASS Parameter 

//SETUP JOB 1249, CORNER, CLASS=M jr 

This job is assigned to class M. ^ 



m 
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The COND Farsaneter— keyword, optional 



^Q 



CLASS 
COND 

The COND parameter specifies whether a job will continue processing based on return codes 
issued by one or more of its job steps. Each test specified by the COND parameter is 
performed using the return code of a completed job step. If any of the tests are satisfied, the 
remaining job steps are bypassed and the job is terminated. 

For further information on the use of the COND parameter, see "Conditional Execution of 
Job Steps." 

COND=( ( code , operator ),...) 

code 

a decimal number from through 4095. This number is compared with the return code 
issued by each job step. 
operator 

the type of comparison to be made with the return code. Operators and their meanings are: 

GT... greater than 

GE... greater than or equal to 

EQ.. .equal to 

NE...not equal to 

LT...less than 

LE...less than or equal to 

Rules for Coding 

• If you code only one return code test, you need not code the outer parentheses. 

• You can code up to eight different return code tests for each job. If specifying more than 
eight tests, a JCL error message is issued and the job abnormally terminates. 

• If you code the COND parameter on the JOB statement and on one or more of the job's 
EXEC statements, the return code tests requested on the JOB statement take precedence over 
those requested on the EXEC statements. Therefore, any return code test requested on the 
JOB statement that is satisfied causes termination of the job, even if the return code test is 
not satisfied for a particular step. 

Examples of the COND Parameter 

//TYPE JOB ( 611 ,402 ), BOURNE, COND=( 7, LT) 

If 7 is less than the return code, the job is terminated. (Any return code less than or equal to 
7 allows the job to continue.) 

//TEST JOB 501 , BAXTER, COND=( ( 20, GE),( 30, LT) ) 

If 20 is greater than or equal to the return code, or 30 is less than the return code, the job is 
terminated. (Any code of 21 through 30 allows the job to continue.) 
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The GROUP Parameter — keyword, optional 



The GROUP parameter is used to allow a RACF-defined user or users to share access to 
RACF-protected data sets. 

GROUP=group name 

group name 

1 to 8 alphameric or national characters which identify the group that the user is associated 
with during the job. The first character must be alphabetic or national. 

Default: If this parameter is omitted and the USER and PASSWORD parameters are coded, the 
default group for the user is used. 

Rule for Coding 

If GROUP is coded, the USER and PASSWORD parameters must also be specified. 

Example of the GROUP Parameter 

//TEST JOB ' D83 , 123456 ' , GROUP=MYGROUP , USER=MYNAME , PASSWORD=ABC 

Requests that the RACF-defined user be associated with the group named MYGROUP for the 
duration of the job. 
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The MSGCLASS Psffsaneter— keyword, optional 



The MSGCLASS parameter specifies the output class to which system messages and JCL 
statements for the job are to be written. 

For further information on use of the MSGCLASS parameter, see "Obtaining Output" for 
either JES2 or JES3. 

MSGCLASS=output class 

output class 

an alphabetic (A-Z) or numeric (0-9) character. 

Default: Determined by the source of the job; that is, the particular card reader or work 
station, or whether the job was submitted by a time-sharing user. 

Rule for Coding 

System messages and output data sets can be routed to the same output class. To do this, code 
the same output class in both the MSGCLASS parameter on the JOB statement and the SYSOUT 
parameter on the DD statements for the data sets. Or, code SYSOUT=* on aU DD statements 
for the SYSOUT data sets you want to default to the MSGCLASS output class of the job. 

Examples of the MSGCLASS Parameter 

//IN JOB GEORGE, MSGCLASS=F 

Specifies an output class. 

//BOTLE JOB MENTLE , MSGLEVEL= (2,0) 

Specifies no output class. In this case, the output class defaults to the MSGCLASS value 
specified by your installation. 



//A1403 


JOB 


MSGCLASS^L 


//STEP1 


EXEC 


PGM=PRINT 


//OUTPUT 


DD 


SYSOUT=L 



Specifies that a job's system messages MSGCLASS parameter and output data set SYSOUT 
parameter are to be routed to the same output class. 
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The MSGLEVEL Fsff2mieter— keyword, optional 



The MSGLEVEL parameter indicates what job output is to be written as part of the output 
listing. The following output can be requested: 

• The JOB statement 

• All input job control statements 

• All cataloged procedure statements for procedures called by any of the job's steps and the 
internal representation of procedure statement parameters after symbolic parameter 
substitution. 

• Allocation, disposition, and allocation recovery messages (allocation/termination messages.) 

For further information on the MSGLEVEL parameter, see "Obtaining Output" for either 
JES2 or JESS. 

MSGLEVEL=( [statements] , [messages] ) 

statements 

a number that indicates which job control statements are to^be written as output from a job. 
The choices are: 

only the JOB statement is to be written. 

1 all input job control statements, cataloged procedure statements, and the internal 
representation of procedure statement parameters after symboUc parameter substitution 
are to be written. 

2 only input job control statements are to be written. 

messages 

a number that indicates what allocation/ termination messages are to be written. 
Choices are: 

no allocation/termination messages are to be written, unless the job terminates 
abnormally. 

1 allocation/ termination messages are to be written. 

Default: For JES2, it is associated by job class. For JES3, it is associated by the operator with 
the particular reader. 

Rule for Coding 

If the second (messages) subparameter is omitted, you do not need to code the parentheses. 

Examples of the MSGLEVEL Parameter 

//GD40 JOB GEORGE, MSGLEVEL=( 2, 1 ) 

Requests that only input statements and all allocation/termination messages be written. 

//PAUL JOB MENTLE , MSGLEVEL=0 

Requests that only the JOB statement be written. 




MSGCLASS 
MSGLEVEL 
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The NOTIFY Fsarameter-~keyword, optional 



The NOTIFY parameter is used to request that a message be sent to a user's time-sharing 
terminal when his background job has completed processing. 

NOTIFY=user identification 

user identification 

a 1 to 7 alphameric identification of the user to be notified. The first character must be 
alphabetic. 

Rules for Coding 

• Code the same user identification that you specify when you start a terminal session (at 
LOGON). 

• Receiving notification that the job has completed processing. For JES2, if you are logged on to 
any processor, you will be immediately notified when the job completes. If you are not 
logged on, the message will be saved and presented when you log on to the system you 
originally submitted the job from. For JES3, if you are logged on to the processor you 
submitted the job from, you will be notified when it completes. If you are not logged on, 
the message will be saved and presented when you log on to the system you originally 
submitted the job from. 

Example of the NOTIFY Parameter 

//SIGN JOB N0TIFY=P0K1 ,MSGLEVEL=( 2, 1 ) 

When the job "SIGN" has completed processing, a message will be sent to the user "POKl" 
informing him that his job has completed processing. 



i 
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The PASSWORD Parameter — keyword, optional 



^Q 



NOTIFY 
PASSWC 

The PASSWORD parameter is used to identify a current RACF password or specify a new RACF 
password. 

PASSWORD=( password [, new password] ) 

password 

1 to 8 alphameric or national characters identifying the user's current password. 
new password 

1 to 8 alphameric or national characters identifying the user's new password. 

Rules for Coding 

• If PASSWORD is coded, the user parameter must also be specified. 

• Parentheses are not needed if the new password subparameter is omitted. 

• You can specify a new password at any time. You must specify a new password when the 
current password has expired. 

Examples of the PASSWORD Parameter 

//TEST1 JOB ' D83 , 1 23456 ' , PAS SWORD- ABODE , USER=MYNAME 

Identifies ABODE as the current password for the RACE user. 

//TEST2 JOB 'DBS, 123456' ,PASSW0RD=(BCH,A12a),USER=RAC1 ,GROUP=GRP 

Requests that the current password BCH be changed to Al2@. 
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The PERFORM Farmneter^keyword, optional 




NOTIFY 
PERFORM 

The PERFORM parameter specifies the performance group definition with which a job is 
associated. 

For information on the performance groups, see "Performance of Jobs and Job Steps" for 
either JES2 or JES3. 

PERFORM=n 

n 

a number between 1 and 255 inclusive, identif5dng a performance group that has been 
defined by the installation. 

Default: The interpreter will obtain a default from the system resources manager and issue a 
warning message indicating a system default is set. 

• For non-TSO jobs, the IBM-supplied default is one (1). 

• For TSO jobs, the IBM-supplied default is two (2). 

• If PERFORM is specified on the JOB statement, its value will supersede any PERFORM 
specifications on EXEC statements associated with the job. 

• If an invalid performance group is specified, the interpreter will obtain a default from the 
system resources manager and issue a warning message indicating nonverification and 
default substitution. 

• If no PERFORM parameter appears on the JOB statement and a PERFORM parameter appears 
on an associated EXEC statement, the parameter value appearing on the EXEC statement will 
be used during the associated job step. 

• If no PERFORM parameter appears on either the JOB or EXEC statements for batch jobs, the 
performance group default is one. 

Example of the PERFORM Parameter 

//STEP1 JOB MARLA,CLASS=D,PERFORM=25 

Class D determines in which class the job will be executed. Once in the system, the job will 
run in performance group 25. The significance of this performance group is defined by the 
installation. 
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Programmer's Name Parameter— /yo^i/io/ia/, optional (according to installation 
procedures) 

The programmer's name parameter identifies the person or group responsible for a job. 

programmer ' s name 

Rules for Coding 

• If the programmer's name parameter is coded, place it after the accounting information 
parameter. 

• Code the programmer's name parameter before any or all keyword parameters. 

• The programmer's name must not exceed 20 characters, including all special characters. 

• When the programmer's name contains special characters, other than periods, enclose the 
name in apostrophes. If the special characters include apostrophes, each apostrophe must be 
coded as two consecutive apostrophes. 

• If the programmer's name parameter is not required, you need not code a comma to 
indicate its absence. 

Examples of the Programmer's Name Parameter 

//APP JOB , C . L . BROWN 

Programmer's name, no accounting information. 

//DELTA JOB 'T.O' 'WEILL' 

Programmer's name containing special characters, no accounting information required. (The 
leading comma may be optional. Check with your installation.) 

//#308 JOB (846349, GROUP 12), GREGORY 

Account number plus additional accounting information and programmer's name. 



\ 
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The PRTY Parameter— itej?»wr</, optional (JES2 only) 



The PRTY parameter specifies a job's queue selection priority: the priority by which the job is 
selected from all internal JES2 queues. For further information about this priority, see "Routing 
a Job Through the System (JES2 only)". 

Note: Depending on the JES2 initialization options specified, the PRTY parameter might be 
ignored. 

PRTY=priority 

priority 

a number from to 15 indicating the job's queue selection priority. The highest priority is 
15. 

Default: Installation default. 

Rule for Coding 

If the priority value is not between and 15, it is ignored by JES2. 

Example of the PRTY Parameter 

//JOBA JOB 1 , 'EXAMPLE JOB' ,PRTY= 12 

The job has a queue selection priority of 12. 




prog name 
PRTY 
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The PRTY Psffameter-— keyword, optional (JES3 only) 




prog name 
PRTY 

The PRTY parameter specifies a job's initiation or selection priority within its job class group. 
(For ASP main processors, when the job is initiated, the system wiQ convert the job's priority 
into dispatching priority so that the job's tasks can compete with other tasks for use of main 
storage and CPU resources.) 

For further information, see "Routing a Job Through the System (JESS only)". 

PRTY=priority 

priority 

a number from to 14 indicating a job's priority. The highest priority is 14. 

Default: Installation default. 

Rule for Coding 

If the priority value is not between and 14, a JCL error will occur. 

Examples of the PRTY Parameter 

//#1930 JOB RICHARDSON, CLASS=C,PRTY=8 

The job wiU have an initiation priority of 8 in the job class C. 



//RING JOB WILLI AMS,PRTY=4 

The job win have an initiation priority of 4. 
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The RD Parameter — keyword, optional 



The RD (restart definition) parameter specifies how the step restart facilities are used with the 
CHKPT macro instruction, and whether automatic restart is permitted or suppressed. 

For detailed information on the checkpoint/restart facility, refer to OS/VS 
Checkpoint/Restart. 




R 

indicates that automatic step restart is permitted. 

If the processing program used by a job step does not include a CHKPT macro instruction, 

coding RD=R allows execution to be resumed at the beginning of the abnormally terminated 

step. 

If the program does include a CHKPT macro instruction, coding RD=R permits automatic 
step restart if the step abnormally terminates before execution of the CHKPT macro 
instruction; thereafter, only checkpoint restart can occur. 

If you cancel the effects of the CHKPT macro instruction before a checkpoint restart is 
performed, the request for automatic step restart is again in effect. 

RNC 

indicates that automatic step restart is permitted and automatic and deferred checkpoint 
restart are not permitted. 

NC 

indicates that automatic step restart and automatic and deferred checkpoint restart are not 
permitted. 

NR 

indicates that a CHKPT macro instruction can establish a checkpoint, but neither automatic 
step restart nor automatic checkpoint restart is permitted. Coding RD=NR allows you to 
resubmit the job at a later time and specify in the RESTART parameter, (on the JOB 
statement of the resubmitted job) the checkpoint at which execution is to be resumed. 



Rules for Coding 



• Automatic restart will not be honored if you do not have a job journal (a job journal is an 
initialization option). 

• Even if you do not code the RD parameter, the job is eligible for automatic 
checkpoint/restart if checkpoints have been issued. However, the job is not eligible for 
automatic step restart. 

• If you code the RD parameter on the JOB statement, any RD parameters coded on the job's 
EXEC statements are ignored and the value coded on the JOB statement is effective for all 
steps. 

• The RD parameter values NC and RNC can be used to suppress the action of the CHKPT 
parameter. 



i 
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Examples of the RD Parameter 



//JILL JOB 333, ERIC, CLASS=C, RD=R, MSGLEVEL=( 1 , 1 ) 

Permits execution to be automatically restarted with a step that abnormally terminates. 

//TRY56 JOB 333, ERNEST, RD=RNC,MSGLEVEL=( 1,1) 

Permits execution to be automatically restarted beginning with a step that abnormally 
terminates; suppresses the action of CHKPT macro instruction. 

//PASS JOB ( 721 ,994), PEOPLE, RD=NR,MSGLEVEL=( 0,1 ) 

Neither automatic step nor checkpoint restart can occur, but CHKPT macro instruction can 
establish checkpoints. 
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The REGION Psffsaneter-^keyword, optional 



The REGION parameter specifies the amount of space to be allocated to a job. 

For further information on the REGION parameter, see the section "Requesting Storage For 
Execution of a Program." 



REGION=valueK 



valueK 

a number that indicates how many bytes of storage are to be allocated to a job. 

Default: the installation-defined default; by job class in JES2 and operator with the particular 
reader in JES3. 



General Rules for Coding 

• Code an even number. (If you code an odd number, the system treats it as the next highest 
even number.) 

• When you want to specify a different region size for each job step, code the REGION 
parameter on the EXEC statements, instead of the JOB statement. 

• If you code the REGION parameter on the JOB statement, REGION parameters coded on the 
job's EXEC statements are ignored, 
if you code the region value as 0, or allow it to default to 0, results are unpredictable. 

Rule for Coding when Using Virtual Storage 

The installation provides a default region size for use when the REGION parameter is not 
specified when ADDRSPC=VIRT is coded or impUed. That value, or the value specified on the 
REGION parameter if coded, sets the upper boundary to limit region size for variable-length 
GETMAlNs as long as there remains in the region at least the minimum amount of storage 
requested. In addition, the region value is used by an IBM or installation-supphed routine 
(lEALlMlT) to estabUsh a second value used to limit fixed-length GETMAlNs, and 
variable-length GETMAlNs when the space remaining in the region is less than the requested 
minimum. When the minimum requested length for variable-length GETMAlNs causes this 
second value to be exceeded, the job or job step abnormally terminates. For further 
information, see OS/VS2 System Programming Library: Job Management. 



^,. 
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Examples of the REGION Parameter 

//SANDY JOB A23,COFFEE,REGION=100K,ADDRSPC=REAL 

lOOK of real storage is assigned. 




REGION 



//ACCT4 JOB 175,FRED,REGION=250K 

A 250K region is assigned. For variable-length getmains, the request is satisfied as long as 
there remains in the region at least the minimum amount requested. If less than the minimum 
remains, the minimum is allocated as long as the allocation does not cause the second limiting 
value (described above) to be exceeded. For fixed-length GETMAINs, the amount requested is 
allocated as long as the allocation does not cause the second limiting value to be exceeded. 
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The RESTART Parameter — keyword, optional 



The RESTART parameter indicates that the restart faciUties are to be used to resubmit a job for 
execution. Execution can be restarted at the beginning of a step (step restart) or within a step 
(checkpoint restart). 

For detailed information on the checkpoint/restart facilities, refer to OS/VS 
Checkpoint/Restart. 

RESTART={ (* \ [,checkid]) 

stepname 
stepname . procstepname 



indicates that execution is to be restarted at or within the first job step. 

stepname 

specifies that execution is to be restarted at or within the named job step. 

stepname.procstepname 

specifies that execution is to be restarted at or within a cataloged procedure step. Stepname 
is the name of the job step that calls the cataloged procedure, and procstepname is the 
name of the procedure step. 

checkid 

specifies the name of the checkpoint at which execution is to be restarted. When checkid is 
coded, execution is restarted within the specified job step at the named checkpoint. If 
checkid is not coded, execution is restarted at the specified job step. 

Rules for Coding 

• Code * in place of stepname.procstepname if the first job step calls a cataloged procedure 
and execution is to be restarted at or within the first procedure step. 

• The first character of stepname must be alphabetic. 

• You need not code the parentheses if execution is to be restarted at a job step; that is, if 
you do not code the checkid subparameter. 

• If the checkpoint name contains special characters, the name must be enclosed in 
apostrophes. If one of the special characters is an apostrophe, identify it by coding two 
consecutive apostrophes in its place. 

• Include the SYSCHK DD statement when execution is to be restarted within a job step. (The 
SYSCHK DD statement is described in the section on DD statements in this publication.) 

• Before resubmitting a job, check all backward references to steps that precede the restart 
step. Eliminate all backward references for the following keywords: PGM and COND on the 
EXEC statements, and VOLUME=REF=reference on the DD statements. A backward 

r^ reference of VOLUME=REF=reference is allowed if the statement to which reference is 
made includes VOLUME=SER= (serial number,...). 

Generation Data Sets 

In the restart step or in steps following it, do not use the original relative generation numbers 
to refer to generation data sets that were created and cataloged in steps preceding the restart 
step. Instead, refer to a generation data set by its present relative generation number. For 
example, if the last generation data set created and cataloged was assigned a generation 
number of +2, refer to it as in the restart step and in steps following the restart step. In this 
case, refer to the generation data set assigned a generation number of +1 as -1. 



150 OS/VS2 JCL (VS2 Release 3.7) 



i 




If generation data sets created in tlie restart step were kept instead of cataloged (that is 
,DISP=(NEW,CATLG,KEEP) was coded and abnormal termination occurred), refer to generation 
data sets during checkpoint restart by the same relative generation numbers that were used to 
create them. restart 

Examples of the RESTART Parameter 

//LINES JOB RESTART=COUNT 

Specifies that execution is to be restarted at the job step name COUNT. 

//aL0C5 JOB RESTART=( PROCESS, CHKPT3) 
//SYSCHK DD DSN=CHK,UNIT=3330,DISP=OLD 

Specifies that execution is to be restarted within the job step named PROCESS at the 
checkpoint named CHKPT3. This JOB statement must be followed by a DD statement named 
SYSCHK, which defines the data set on which an entry for the checkpoint name CHKPT3 was 
written. 

//WORK JOB RESTART=(*,CKPT2) 

//SYSCHK DD DSNAME=CHKPT,UNIT=3330,DISP=OLD 

Specifies that execution is to be restarted at the checkpoint name CKrT2 in the first job step. 
This JOB statement is followed by a DD statement name SYSCHK, which defines the data set 
on which an entry for the checkpoint name CKPT2 was written. 

//CLIPS JOB RESTART= ( PAY . WEEKLY , CHECKS ) 
//SYSCHK DD DSN=CHKPT,UNIT=2314,DISP=OLD 

Specifies that execution is to be restarted within the procedure step named WEEKLY at the 
checkpoint name CHECKS. PAY is the name of the job step that calls the cataloged procedure 
that contains the procedure step named WEEKLY. This JOB statement must be followed by a 
DD statement named SYSCHK, which defines the data set on which an entry for the checkpoint 
named CHECKS was written. 
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The TIME Psacsaneter— keyword, optional J 

The TIME parameter specifies the maximum amount of time that a job may use the CPU. The 
CPU time used by the job is written on the output listing. 



\i 



TIME= i( [minutes] [, seconds' 
1440 



minutes 

a number that specifies the maximum number of minutes the job can use the CPU. The 
number of minutes must be less than 1440 (24 hours). 

seconds 

a number that specifies the maximum number of seconds beyond the specified number of 
minutes the job can use the CPU, or if no minutes are specified, the maximum number of 
seconds the job can use the CPU. The number of seconds must be less than 60. 

1440 

specifies that the job is not to be timed. 

Rules for Coding 

• If you code the CPU time limit in minutes only, you need not code the parentheses. If you 
code the CPU time limit in seconds only, code a comma preceding the seconds to indicate 
the absence of minutes. 

• Code 1440 if the job can use the CPU for 24 hours or more or if any of the job's steps 
should be allowed to remain in a wait state for more than the established time Umit. 

• A job that exceeds the specified limit causes termination of the job unless you use a user 
exit routine to extend the time. 

• TIME=0 is not supported. Results are unpredictable when used on the JOB statement. 

• If the TIME parameter is coded on the JOB statement with a value other than 1440, the time 
limit for each step is set to the step time limit (the value coded on the time parameter of 
the EXEC statement or the limit specified by the installation) or the remaining job time, 
whichever is smaller. 

• If the TIME parameter is not coded on the JOB statement, each job step is timed individually 
according to the value coded on the TIME parameter of the exec statement or the limit 
specified by the installation. 

Examples of the TIME Parameter 

//SEED JOB TIME=(12,10) 

Specifies that the maximum amount of time the job can use the CPU is 12 minutes, 10 
seconds. 

//TYPE41 JOB TIME=(,30) 

Specifies that the maximum amount of time the job can use the CPU is 30 seconds. 

//FORMS JOB TIME=5 

Specifies that the maximum amount of time the job can use the CPU is 5 minutes. 

//RAINCK JOB TIME=1440 

Specifies that the job is not timed. Therefore, the job may use the CPU and may remain in 
wait state for an unspecified period of time. 
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The TYPRUN Parameter — keyword, optional 

TIME 
TYPRUN 

The TYPRUN parameter specifies special JES2 and JES3 processing. The operator must be 
informed of what event is to occur. When the event has occurred, the operator releases the job 
from hold status, thereby allowing it to be selected for processing. The TYPRUN parameter can 
also specify that the JCL for a job be scanned for syntax errors and, for JES2, that the input 
deck is converted directly to a SYSOUT data set and scheduled for output processing. 

For further information on the TYPRUN parameter, see "Delaying Job Initiation" and 
"BjTJassing Job Initiation." 

SHOLD / 
SCAN > 
COPY ) 

HOLD 

Specifies that the job is to be held in the input queue until the operator releases the job. 

SCAN 

specifies that the JCL for a job is to be scanned for syntax errors but that the job is not to 
be executed. For example, SCAN checks for invalid keywords, illegal characters, and 
parentheses errors. SCAN does not check for parameter value errors or excessive parameters 
in JES2 but does check for these in JES3. SCAN does not check for misplaced statements. 

COPY 

(For JES2 only) specifies that the input deck (as submitted) is converted directly to a 
SYSOUT data set and scheduled for output processing. The class of the SYSOUT data set is 
the same as the message class of the job and can be controlled by the MSGCLASS 
parameter. This feature is available in JES3 by using nonstandard job processing. (See the 
section, "The PROCESS Statement" for information concerning nonstandard job 
processing.) 

Example of the TYPRUN Parameter 

//UPDATE JOB 

//LIST JOB TYPRUN^HOLD 

Jobs UPDATE and LIST are to be submitted for execution. The job UPDATE uses a program 
that adds and deletes members to a library; the job LIST uses a program that lists the members 
of a library. For an up-to-date listing of the library, UPDATE must be executed before LIST. 
This is accompUshed by coding TYPRUN=HOLD on the JOB statement for the job named LIST. 
If a MONITOR JOBNAMES command is issued by you or the operator, the operator is notified 
on the console when UPDATE has completed processing. The operator releases LIST, which can 
then be selected for execution. 
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The USER Parameter — keyword, optional 



The USER parameter is used to specify a RACF userid for identification. 



USER^userid 



userid 

1 to 7 alphameric or national characters that identify the RACF-defined user to the system. 
The first character must be alphabetic or national. 

Default: If this parameter and the GROUP parameter are omitted, RACE assigns a default 
userid and group name. 

Rule for Coding 

If USER is coded, the PASSWORD parameter must also be specified. 

Example of the USER Parameter 

//TEST JOB 'D83, 123456' ,USER=MYNAME,PASSWORD=ABCD 

Identifies MYNAME as the userid for this RACF-defined user. 
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The TYPRUN Parameter— •it^yn'ori/, optional 



The TYPRUN parameter specifies special JES2 and JESS processing. For TYPRUN=HOLD or 
TYPRUN=JCLHOLD, the operator must be informed of what event is to occur. When the event 
has occurred, the operator releases the job from hold status, thereby allowing it to be selected 
for processing. The TYPRUN parameter can also specify that the JCL for a job be scanned for 
syntax errors and, for JES2, that the input deck is converted directly to a SYSOUT data set and 
scheduled for output processing. 

For further information on the TYPRUN parameter, see "Delaying Job Initiation" and 
"Bypassing Job Initiation." 

/HOLD \ 

JJCLHOLD? 

TYPRUN=)SCAN ( 

tcopY ; 

HOLD 

specifies that the job is to be held prior to execution until the operator releases the job. 
JCLHOLD 

(for JES2 only) specifies that the job is to be held before processing by the JCL converter 
until the operator releases the job. 

SCAN 

specifies that the JCL for a job is to be scanned for syntax errors but that the job is not to 
be executed. For example, SCAN checks for invalid keywords, illegal characters, and 
parentheses errors. SCAN does not check for parameter value errors or excessive parameters 
in JES2 but does check for these in JES3. SCAN does not check for misplaced statements. 

COPY 

(for JES2 only) specifies that the input deck (as submitted) is converted directly to a 
SYSOUT data set and scheduled for output processing. The class of the SYSOUT data set is 
the same as the message class of the job and can be controlled by the msgclass 
parameter. This feature is available in JES3 by using nonstandard job processing. (See the 
section, "The PROCESS Statement" for information concerning nonstandard job 
processing.) 

Examples of the TYPRUN Parameter 

//UPDATE JOB 

//LIST JOB TYPRUN=HOLD 

Jobs UPDATE and list are to be submitted for execution. The job UPDATE uses a program 
that adds and deletes members to a library; the job LIST uses a program that lists the members 
of a library. For an up-to-date listing of the library, UPDATE must be executed before LIST. 
This is accompHshed by coding TYPRUN=HOLD on the JOB statement for the job named LIST. 
If a MONITOR JOBNAMES command is issued by you or the operator, the operator is notified 
on the console when update has completed processing. The operator releases LIST, which can 
then be selected for execution. 

//UPDTPROC JOB 

//TESTPROC JOB TYPRUN=JCLHOLD 

Jobs UPDTPROC and TESTPROC are to be submitted for execution. The job UPDTPROC adds a 
cataloged procedure to SYSl.PROCLIB; the JCL in job TESTPROC invokes the new procedure. 
The second JOB statement specifies TYPRUN=JCLHOLD so that TESTPROC will not be 
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processed by the JCL converter until the required procedure has been added to the library by 
UPDTPROC. The operator releases TESTPROC after UPDTPROC has executed. 
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The EXEC Statement 



Control Statement 



The EXEC statement is the first statement of each job step and cataloged procedure step. It 
identifies the program to be executed or the cataloged procedure to be called. 



r 



//stepname EXEC operands comments 




The EXEC statement consists of the characters // in columns 1 and 2 and four fields — the 
name, operation (EXEC), operand, and comments fields. 



General Rules for Coding 



• Code an EXEC statement for each job step. 

• A stepname is optional. However, when you want to perform certain functions, you should 
code a valid and unique stepname in the name field for each job step within the job. A 
stepname is necessary to: 

• Make backward references to the step. 

• Override parameters on an EXEC statement or DD statement in a cataloged procedure 
step, and add dd statements to a cataloged procedure step. 

• Perform a step or checkpoint restart at or within the step. 

• The stepname must consist of 1 through 8 alphameric and national (@,#,$) characters. The 
first character must be an alphabetic or national character. 

• The two types of parameters that can be coded in the operand field of the EXEC statement 
are: 

Positional parameterSf which must precede any keyword parameter. One of the following three 
positional parameters must be coded: 

PGM 
PROC 

procedure name 

Keyword parameters, which can be coded in any order after the positional parameter. Any of 
the following keyword parameters can be coded on the EXEC statement: 

ACCT 

ADDRSPC 

COND 

DPRTY 

DYNAMNBR 

PARM 

PERFORM 

RD 

REGION 

TIME 



Sample EXEC Statements 



//STEP4 


EXEC 


PGM=DREC , PARM= ' 3 1 8 , NO ' 


// 


EXEC 


PGM=ENTRY , TIME=( 2,30) 


//FOR 


EXEC 


PROC=PE489,TIME=4 
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The ACCT Psarsaneter-^keyword, optional i 



The ACCT parameter specifies one or more subparameters of accounting information to be 
passed to the installation's accounting routines. 

For further infonnation concerning the accounting routines, see OS/VS System Management 
Facilities (SMF). 

ACCT [ .procstepname]=( accounting information, . , . ) 

accounting information 

specifies one or more subparameters established by the installation as accounting 
information to be passed to the accounting routines. 

Rules for Coding 

• If the accounting information consists of only one subparameter, you need not code the 
parentheses. 

• The maximum number of characters of accounting information, including the commas that 
separate the subparameters, is 142. 

• If a subparameter contains special characters (other than hyphens), enclose the 
subparameter in apostrophes. The apostrophes are not considered part of the information. If 
one of the special characters is an apostrophe, code two consecutive apostrophes in its 
place. 

• If the job step calls a cataloged procedure, the ACCT parameter overrides any ACCT ■ 
parameters coded in the procedure steps. This pertains to all procedure steps. "' 

• If different steps in a cataloged procedure required different accounting information, code 
ACCT.procstepname= (accounting information,...) for each step that requires unique 
accounting information. Accounting information will then pertain only to the named 
procedure step. 

Examples of the ACCT Parameter 

//STEP1 EXEC PGM=JP5,ACCT=( LOCATIONS, 'CHGE+3' ) 

Specifies that this accounting information pertains to this job step. 

//STP3 EXEC LOOKUP, ACCT=( V83468' ) 

Specifies that this information pertains to this job step. Since this step calls a cataloged 
procedure, the accounting information pertains to all the steps in the procedure. 

//STP4 EXEC BILLING, ACCT. PAID=563 70, ACCT. LATE=56470, 
// ACCT . BILL= '121 +366 ' 

Specifies that different accounting information pertains to each of the named procedure steps 
(PAID,LATE, and BILL). 
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The ADDRSPC Parameter— Ar^^^woi-^, optional 



The ADDRSPC parameter indicates whether the job step will use virtual or real storage, that is, 
whether or not the job step can be paged. 

For further information on the ADDRSPC parameter, see the section "Requesting Storage 
For Execution of a Program". 




EXEC 



ADDRSPC^ S VIRT ) ACCT 

/ REAL ( ADDRSPC 

VIRT 

a ke5rword indicating that the job step can be paged to virtual storage. 

REAL 

a keyword indicating that the job step cannot be paged. The job step must exist in real 
storage. 

Default: If you omit the ADDRSPC parameter, the default is VIRT, unless the installation has 
changed the default. 

General Rules for Coding 

• The ADDRSPC parameter coded on a JOB statement will override any ADDRSPC parameter 
coded on an EXEC statement for that job. 

• Requests for real and virtual storage can be made in the same job. Each step will honor the 
request for either real or virtual storage if there is no ADDRSPC parameter on the JOB 
statement. 

Rule for Coding when Using Real Storage 

I Code the REGION parameter to specify how much storage is needed, or allow it to default. 

Rule for Coding when Using Virtual Storage 

The installation provides a default region size for use when the REGION parameter is not 
specified when ADDRSPC=VIRT is coded or implied. That value, or the value specified on the 
REGION parameter if coded, sets the upper boundary to limit region size for variable-length 
GETMAlNs as long as there remains in the region at least the minimum amount of storage 
requested. In addition, the region value is used by an IBM or installation-supplied routine 
IEALIMIT) to establish a second value used to limit fixed-length GETMAlNs, and variable-length 
GETMAlNs when the space remaining in the region is less than the requested minimum. When 
the minimum requested length for variable-length GETMAlNs causes this second value to be 
exceeded, the job or job step abnormally terminates. For further information, see OS/VS2 
System Programming Library: Job Management. 
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Examples of the ADDRSPC Parameter 



//CAC1 EXEC A,ADDRSPC=VIRT 

The ADDRSPC parameter requests virtual storage. The area size available to the user is the 
installation-supplied default, or the region size specified on the JOB statement, since the 
REGION parameter is not coded. 



r 



//CAC2 EXEC B,ADDRSPC=REAL,REGION=80K 

The ADDRSPC parameter requests real storage. The REGION parameter specifies the amount, in 
this case, 80K. 



( 
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The COND FwrsLmeter-^keyword, optional 



I The COND parameter specifies whether a job step will be executed based on return codes 
issued by one or more of the preceding job steps. This parameter allows the specification of 
conditions for bypassing a job step, as well as for executing a job step. 

Each test specified by the COND parameter is performed using the return code of a 
completed job step. If any of the tests are satisfied, the particular job step is bypassed. 

For further information on the use of the COND parameter, see "Conditional Execution of 
Job Steps." 




ADDRSPC 
COND 



COND= ( r( code , operator ) 

( code , operator , stepname ) 
I ( code , operator , stepname . procstepname ) 



, ] fEVENl ) 
LONLYj 



code 

a number from through 4095. This number is compared with the return code issued by all 
previous steps or a specific step. 
operator 

the type of comparison to be made with the return code. Operators and their meanings are: 

GT... greater than 

GE... greater than or equal to 

EQ... equal to 

LT...less than 

LE...less than or equal to 

NE...not equal to 

Stepname 

the name of a preceding job step that issued the return code to be tested. 
stepname.procstepname 

the "stepname"is the name assigned to the step requesting execution of a procedure and 
"procstepname" is the name of the step within the procedure that issued the return code to 
be tested. 

EVEN 

specifies that the job step is to be executed even if one or more preceding job steps have 
abnormally terminated. If return code tests are to be made and any tests are satisfied, this 
job step is bypassed. 
ONLY 

specifies that the job step is to be executed only if one or more preceding job steps have 
abnormally terminated. If the current job step specifies that return code tests are to be 
made and if any tests are satisfied, this job step will be bypassed. 



Rules for Coding 



Return code tests against preceding steps that do not run are ignored and the current step is 

executed. 

If COND is coded on the JOB statement, then it will be ignored on the EXEC statement. 

If you code neither EVEN nor ONLY, you can make up to eight tests on return codes issued 

by preceding job steps or cataloged procedure steps that completed normally. If you code 

EVEN or ONLY, you can make up to seven tests on return codes. If you specify more than 

eight tests, a JCL error message is issued and the job fails. 

If you code only even or ONLY, or if you code only one test, you need not code outer 

parentheses. 
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• If a job step that specifies the EVEN or ONLY subparameter refers to a data set that was to 
be created or cataloged in a preceding step, the data set may be incomplete if the step 
creating it abnormally terminated. 

• You can code the EVEN or ONLY subparameters before, between, or after return code tests. 

• If you want each return code test to be made on the return code issued by every preceding 
step, do not code a stepname or procstepname. 

• If ONLY is specified on the first job step and a JOBLIB is being used, the unit and volume 
information are not passed to the succeeding step and the catalog will be searched for the 
JOBLIB data set. 

• If a job step refers to a data set created in a preceding step, that data set will not exist if 
the preceding step was bypassed. If a data set was cataloged in a preceding job step and 
you make a backward reference to that data set, unit and volume information for the data 
set will not be available if the preceding step was skipped. 

Code COND on the EXEC statement for any of the following: 

• When you want to specify different tests for each job step. 

• If a test you specify is true, you want to skip just that one step, rather than bypassing all 
subsequent steps in the job. 

• When you want to name a specific step whose return code is to be tested. 

• When you want to specify special conditions for executing a job step. 

Examples of the COND parameter 

//STEP6 EXEC PGM=BAB , COND=( 4 , GT , STEPS ) 

If 4 is greater than the return code issued by STEP3 the system will bypass the step. (A return 
code of 4 or greater from STEP3 allows this step (STEP6) to be executed.) Since neither EVEN 
nor ONLY is specified, this job step will be automatically bypassed if a preceding step 
abnormally terminates. 

//TEST2 EXEC PGM=BACK,COND=( ( 1 6,GE ) , ( 90 , LE, STEP1 ) ,ONLY ) 

If 16 is greater than or equal to the return code issued by any of the preceding job steps or if 
90 is less than or equal to the return code issued by STEPl, this step will be bypassed. If none 
of the tests are satisfied and a preceding job step has abnormally terminated, this step will be 
executed because ONLY is coded. 

//STP4 EXEC BILLING, COND. PAID={ ( 20, LT), EVEN), 

// COND. LATE=( 60, GT, FIND), 

// COND.BILL=( ( 20,GE),( 30,LT,CHGE) ) 

This example specifies that different return code tests pertain to each of the named procedure 
steps (PAID, LATE, and bill). If the return code test specified for the procedure step named 
PAID is not satisfied, the step will be executed even if a preceding step abnormally terminates. 
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The DPRTY Fsarsasketer— keyword, optional 



The DPRTY parameter assigns a dispatching priority to a job step. Dispatching priority will be 
used by the system resources manager in determining the order in which tasks will be 
executed. 

For further information on the use of the DPRTY parameter, see "Assigning a Dispatching 
Priority to Job Steps" for either JES2 or JES3. 

DPRTY [ .procstepname] =( [ value 1] [,value2] ) 

valuel 

a number from through 15 which indicates whether the job step is to have the same 
priority or a different priority than the job. The job priority is coded on the JES2 PRIORITY 
statement or cdculated from values specified in the accounting information on the JOB 
statement, the JOBPARM values, or an installation default. 
value2 

a number from through 15 which the system adds to valuel to form the dispatching 
priority. The system forms the internal priority by converting the value assigned to valuel in 
the DPRTY parameter. 

Default: If you omit the DPRTY parameter completely, the job step is assigned the APG 
priority. If valuel is omitted or it is equal to the APG value, the step is assigned the APG 
priority and any value you code for value2 is ignored. In this case, value2 is obtained from the 
Installation Performance Specification (iPS) using the performance group associated with the 

job step. (See OS/VS2 System Programming Library: Initialization and Timing Guide for information on 
IPS.) If value2 is not specified in the IPS, a value of 6 is assigned to value2. 

General Rules for Coding 

• If you omit valuel, you must code a comma preceding value2 to indicate the absence of 
valuel. 

• If you omit value2, you need not code the parentheses. 

Cataloged Procedures 

• You can code the DPRTY parameter on the EXEC statement of a cataloged procedure. 

• If a job step calls a cataloged procedure: 

To override all DPRTY parameters code the DPRTY parameter on the EXEC statement that calls 
the cataloged procedure. This will estabhsh one dispatching priority for all steps in the 
procedure. 

To override only certain DPRTY parameters code DPRTY[.procstepname] on the EXEC statement 
that calls the procedure for each procedure step that you want to override. The dispatching 
priority wiU than pertain only to the named procedure step. 

Example of the DPRTY Parameter 

//BP2 EXEC PGM=FOUR , DPRTY=( 13,9) 

The system uses these numbers to form a dispatching priority for this step. Since the numbers 
are high, the dispatching priority will be high. 
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The DYNAMNBR Parameter— ifc^>wori/, optional 



The DYNAMNBR parameter specifies that a number of resources can be held in anticipation of 
reuse. DYNAMNBR can be coded instead of coding several DD DYNAM statements. 

For further information on the DYNAMNBR parameter, see "Dynamically Allocating and 
Deallocating Data Sets." 

DYNAMNBR [ . procstepname] =n 

procstepname 

specifies the procedure step to which "n" applies. 
n 

specifies the number of DD DYNAM statements that you would otherwise have had to code; 
from 1 to 1635. 

Default: 

If DYNAMNBR is coded incorrectly, zero is assumed and a warning message is issued. 

Rules for Coding 

• The maximum number of DD DYNAMs plus the number of DYNAMNBRs which can be 
concurrently allocated is 1635. 

• If procstepname is omitted, DYNAMNBR applies to all steps in the procedure. 

Example of the DYNAMNBR Parameter 

//STEP 1 EXEC ■ ACCT , DPRTY=( 13,9), DYNAMNBR . CALC= 1 2 

This statement specifies that 12 allocations in the step CALC can be held in anticipation of 
reuse. 
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The PARM Fsffsaneter— keyword, optional 



The PARM parameter passes variable information to a program in execution. For further 
information on the PARM parameter, see OS/VS2 Supervisor Services and Macro Instructions. 

PARM=value 
value 

,^^ , r . r • 1 . 1 , ■ . DYNAMNBR 

up to 100 characters of mformation which the system is to pass to a processing program. farm 




General Rules for Coding 



Before coding the PARM parameter, see Figure 8, "Character Sets" for an explanation of 

alphameric, national, and special characters. 

If the value contains more than one expression separated by commas, you must enclose it in 

apostrophes or parentheses; that is, PARM='P1,123,MT5' or PARM=(P1,123,MT5). 

Enclosing apostrophes and parentheses are not passed to the processing program; commas 

within apostrophes and parentheses are passed as part of the value. 

If you include special characters in any expression, either (1) enclose the value in 

apostrophes, or (2) enclose the expression in apostrophes and the value in parentheses; that 

is, PARM='P50,12+80' or PARM=(P50,'12+80'). (The enclosing apostrophes and 

parentheses are not passed as part of the value.) 

If one of the special characters is an ampersand and you are not defining a symbolic 

parameter, code two consecutive ampersands in its place; that is, parm='3462& & 5'. 

When two apostrophes or two ampersands are coded, only one is passed to the processing 

program. 

If you must continue the value on another statement, enclose it in parentheses. The 

continuation comma is considered part of the value field and counts toward the maximum of 

100 characters of data. Any expression that contains special characters must be enclosed in 

apostrophes and cannot be continued on the next statement. 



Calling Cataloged or In- stream Procedures 



If a job step calls a cataloged or in-stream procedure, you can pass information to the first 

procedure step and nullify all other PARM parameters in the procedure or override some of 

the PARM parameters contained in the procedure. 

To nullify the PARM parameters in the procedure, code the PARM parameter on the EXEC 

statement that calls the procedure. The information contained in the PARM parameter is 

passed to the first procedure step and PARM parameters in all other procedure steps are 

nullified. 

To override some of the PARM parameters contained in the procedure, code, on the EXEC 

statement that calls the procedure, PARM.procstepname for each procedure step that you 

want to override. Information provided in the PARM value is passed only to the named 

procedure step. 
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Examples of the FARM Parameter 

//RUN3 EXEC PGM=APG22,PARM='P1,123,P2=5' 

Passes the information in the FARM parameter, except the apostrophes, to the processing 
program named APG22. 

// EXEC PR0C8 1 , PARM=MT5 

Passes this information to the first step of the procedure named PROC81. If any of the other 
procedure steps in PR0C81 contain the FARM parameter, those parameters are nullified. 

//STP6 EXEC ASMFCLG , PARM . LKED=( MAP , LET ) 

Passes this information to the procedure step named LKED. If any of the other procedure steps 
in ASMFCLG contain the FARM parameter, those parameters are still in effect. 
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//RUN4 
// 



EXEC 
DECK) 



PGM=IFOX00 , PARM=( NOOBJECT , ' LINECNT=50 ' , 



Passes the information in the FARM parameter, except the apostrophes and the parentheses, to 
the processing program named IFOXOO. When specifying additional FARM expressions on a 
continuation card, the entire value must be enclosed in parentheses. Any expression within 
apostrophes must be contained on a single statement. 
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The PERFORM Farsmeter— keyword, optional 



The PERFORM parameter specifies the performance group definitions to which a job step is 
associated. 

For further information on the performance groups, see "Performance of Jobs and Jobs 
Steps." 




EXEC 



PERFORM [ .procstepname]=n FARM 
PERFORM 

procstepname 

specifies the name of a step within a procedure invoked by this EXEC statement. 
n 

is a number between 1 and 255, inclusive, identifying a performance group that has been 
defined by the installation. 

Default: The interpreter will obtain a default from the system resources manager and issue a 
warning message indicating a system default is set. 

• For non-TSO jobs, the IBM-supplied default is one (1). 

• For TSO jobs, the IBM-supplied default is two (2). 

• If an invalid performance group is specified, the interpreter will obtain a default from the 
system resources manager and issue a warning message indicating nonverification and 
default substitution. 

• Specifying an invalid procstepname also results in a warning message, but no other action, 

• If no PERFORM parameter is specified on either the JOB or EXEC statements, the 
performance group defaults to one. 

Rules for Coding 

• If PERFORM is specified for a procedure, the specified value is effective for the entire 
procedure. If PERFORM.procstepname is coded for a procedure, the value is effective only 
for the procedure step named. 

• If PERFORM is specified on the JOB statement, its value will supercede any PERFORM 
specifications on EXEC statements associated with the job. If no PERFORM parameter 
appears on the JOB statement and a perform parameter appears on an associated EXEC 
statement, the parameter value appearing on the EXEC statement will be used during the 
associated job step. 

Example of the PERFORM Parameter 

//STEPA EXEC PGM=ADAM,PERFORM=60 

This job step will be ran in performance group 60. The significance of this performance group 
is defined by the installation. 
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The PGM Parameter-— /yonrrona/, optional % 



The PGM parameter specifies a program to be executed. The specified program must be a 
member of a temporary library, a system library, or a private library. 

For further information on identifying programs and on Ubraries (partitioned data sets), see 
"Identifying Data Sets to the System." 

PGM= { program name 

< *.stepname.ddname 

( * .stepname.procstepname.ddname 

program name 

specifies the member name or alias of the program to be executed. 

*.stepname.ddname 

specifies a backward reference to a DD statement that defines, as a member of a partitioned 
data set, the program to be executed. Stepname is the name of the step in which the DD 
statement appears; ddname is the name that appears on the DD statement. 
This form of the parameter is usually used when a previous job step has created a 
temporary partitioned data set to store a program until the program is required. 

^.stepname.procstepname.ddname 

specifies a backward reference to a DD statement within a cataloged procedure step that 
defines, as a member of a partitioned data set, the program to be executed. Stepname is the 
name of the step that calls the procedure; procstepname is the name of the procedure step 
that contains the DD statement . 



< 



Rules for Coding 



If you code the PGM parameter, code it as the first parameter on the EXEC statement. The 

program you specify must be a member of a partitioned data set. 

The program name must consist of up to 8 alphameric or national characters, the first of 

which must be alphabetic or national. 

For compatability with ASP (running under JES3), if you code PGM=JCLTEST, you can scan 

the job's JCL without executing the job or setting up devices. This is the same function as 

coding TYPRUN=SCAN on the JOB statement. 
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Examples of the PGM Parameter 

//STEP1 EXEC PGM=TABULATE 

Specifies that the program named TABULATE is a member of SYsI.linklib. 

//JOBS JOB MSGLEVEL=( 2,0) 

//JOBLIB DD DSNAME=DEPT12.LIB4,DISP=(0LD,PASS) 

//STEP1 EXEC PGM=USCAN 

Specifies that the system is to look for the program name USCAN in a private library named 
DEPT12.LIB4. 

//CREATE EXEC PGM=IEWL 

//SYSLMOD DD DSNAME=SSPARTDS( PROG ) ,UNIT=23 14, DISP=( MOD, PASS ) , 

SPACE( 1024,(50,20,1 )) 
//EXECUTE EXEC PGM=* . CREATE . SYSLMOD 

Uses a backward reference to a DD statement that defines a temporary library created in the 
step named CREATE. The program name PROG is stored as a member of the partitioned data 
set named &&PARTDS and will be executed in the step name EXECUTE. &&PARTDS will be 
deleted at the end of the job, 

PGM=UPDT 

DSNAME=SYS 1 ..LINKLIB( P40 ) , DISP=OLD 

PGM=* . STEP2 . DDA 

Uses a backward reference to a DD statement that defines a system library. The program 
named P40 is stored as a member of SYSI.LINKLIB and is executed in the step named STEP3. 

//CHECK EXEC PGM=IEFBR14 

Executes the program named IEFBR14, allowing you to satisfy space allocation and disposition 
processing requests prior to executing your program. The remaining job control statements in 
the job are also checked for syntax. 




EXEC 
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//STEP2 


EXEC 


//DDA 


DD 


//STEP3 


EXEC 
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The PROC and Procedure Name Parameters— posirfona/, optional 



The PROC parameter specifies that a cataloged procedure or an in-stream procedure is to be 
called and executed. 

For further information on cataloged and in-stream procedures, see "Using Cataloged and 
In-Stream Procedures." 

\ PROC=procedure name ) 
\ procedure name \ 

procedure name 

the member name (or alias) of a cataloged procedure or the name of an in-stream procedure 
to be called and executed. 

Rules for Coding 

• The procedure name must consist of one through eight alphameric or national characters of 
which the first must be alphabetic or national. 

• The PROC and PGM parameters are mutually exclusive. Therefore, if you code PGM, do not 
code PROC. If you code the PROC parameter, code it as the first parameter on the EXEC 
statement, instead of the PGM parameter. You can code only the cataloged or in-stream 
procedure name, omitting PROC. 

• When the EXEC statement specifies a cataloged or in-stream procedure, parameters in the 

operand field of the EXEC statement will override EXEC parameters in the called procedure. J 

• Any DD statements that follow the EXEC statement will be treated as overriding DD % 
statements or DD statements that are to be added to the cataloged or in-stream procedure 

for the duration of the job step. 

Examples of the PROC Parameter 

//SP3 EXEC PROC=PAYWKRS 

Specifies that the cataloged or in-stream procedure named PAYWKRS is to be called. 

//BK EXEC OPERATE 

Specifies that the cataloged or in-stream procedure named OPERATE is to be called. This 
specification has the same effect as coding PROC=OPERATE. 
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The RD Parameter — keyword, optional 



The RD (restart definition) parameter specifies how the step restart facilities are used with the 
CHKPT macro instruction, and whether automatic restart is permitted or suppressed. 

For detailed information on the checkpoint/restart facilities, refer to OS/VS 
Checkpoint/Restart. 

( RNcI 

RD [ . procs tepname ] = j NC ^ 

INR ; 

procstepnaine 

applies to the named procedure step. 

R 

indicates that automatic step restart is permitted. 

If the processing program used by a job step does not include any CHKPT macro 

instructions, coding RD=R allows execution to be resumed at the beginning of the 

abnormally terminated step. 

If the program does include a CHKPT macro instruction, coding RD=R permits automatic 

step restart to occur if the step abnormally terminates before execution of the CHKPT macro 

instruction; thereafter, only checkpoint restart can occur. 

If you cancel the effects of the CHKPT macro instruction before a checkpoint restart is 

performed, the request for automatic step restart is again in effect. 

RNC 

indicates that automatic step restart is permitted and automatic and deferred checkpoint 
restart are not permitted. 

NC 

indicates that automatic step restart and automatic and deferred checkpoint restart are not 
permitted. 

NR 

indicates that a CHKPT macro instruction can establish a checkpoint, but neither automatic 
step restart nor automatic checkpoint restart is permitted. Coding RD=NR allows you to 
resubmit the job at a later time and specify in the RESTART parameter (on the job 
statement of the resubmitted job) the checkpoint at which execution is to be resumed. 

Rules for Coding 

• Automatic restart will not be honored if you do not have a job journal. The journal data set 
in JESS is used if one of the following exists: 

• RD= is specified on the JOB or EXEC statement. 

• JOURNAL=YES is specified on the JESS MAIN statement. 

• JOURNAL=YES is specified on the CLASS initiaUzation statement for this job, and was not 
overridden by the JES3 MAIN statement. 

• Even if you do not code the RD parameter, you job is eligible for automatic checkpoint 
restart if checkpoints have been issued. However, the job is not eligible for automatic step 
restart. 

• Code the RD parameter on EXEC statements instead of the JOB statement when you want to 
make different restart requests for each job step. 
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RD 



If you code the RD parameter on the JOB statement, any RD parameters coded on the job's 
EXEC statements are ignored and the value coded on the JOB statement is effective for all 
steps. 

• The RD parameter can be coded on the EXEC statement of a cataloged procedure. If the job 
step does call a cataloged procedure: 

To override all RD parameters, code the RD parameter on the EXEC statement that calls the 
procedure. This establishes one restart for all the steps in the procedure. 

To override only certain RD parameters, code, on the EXEC statement that calls the 
procedure, RD.procstepname for each procedure step that you want to override. The restart 
request will then pertain only to the named procedure step. 

• The RD parameter applies to the step corresponding to the statement or to all steps of the 
cataloged procedure referred to by the statement. 

• RD.procstepname applies to the specified procedure step and overrides the reI parameter 
that may be coded on the EXEC statement of the procedure step. It can be coded once for 
each step of the procedure. 

• The RD parameter values NC and RNC can be used to suppress the action of the CHKPT 
parameter. 

Examples of the RD Parameter 

//STEP1 EXEC PGM=GIIM,RD=R 

Permits execution to be automatically restarted with this step if it abnormally terminates. 

//NEST EXEC PGM=T 1 8 , RD=RNC 

Permits execution to be automatically restarted with this step if it abnormally terminates; 
suppresses the action of CHKPT macro instructions issued in the program this job step uses. 

//CARD EXEC PGM=WTE , RD=NR 

Neither automatic step restart nor automatic checkpoint restart can occur, but CHKPT macro 
instructions issued in the program that this job step executes can estabUsh checkpoints. 

//STP4 EXEC BILLING, RD.PAID=NC,RD.BILL=NR 

Specifies that different restart requests pertain to each of the named procedure steps (paid 
and BILL). 
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The REGION Paisaneter— keyword, optional 



The REGION parameter specifies the amount of space to be allocated to a job. 

For further information on the REGION parameter, see the section "Requesting Storage For 
Execution of a Program." 

REGION=valueK 

valueK 

specifies a number that indicates how many bytes of storage are to be allocated to a job 
step. 

Default: the installation-defined default. 




EXEC 



RD 
REGION 



General Rules for Coding 



Code an even number. (If you code an odd number, the system treats it as the next highest 

even number.) 

When you want to specify a different region size for each job step, code the REGION 

parameter on the EXEC statements, instead of the JOB statement. 

If the REGION parameter is coded on the JOB statement, REGION parameters coded on the 

job's EXEC statements are ignored. 

If you code the region value as 0, or allow it to default to 0, results are unpredictable. 



Rule for Coding when Using Virtual Storage 

The installation provides a default region size for use when the REGION parameter is not 
specified when ADDRSPC=VIRT is code or implied. That value, or the value specified on the 
REGION parameter if coded, sets the upper boundary to limit region size for variable-length 
GETMAlNs as long as there remains in the region at least the minimum amount of storage 
requested. In addition, the region value is used by an IBM or installation-supplied routine 
(lEALlMlT) to estabUsh a second value used to limit fixed-length GETMAlNs, and 
variable-length GETMAlNs when the space remaining in the region is less than the requested 
minimum. When the minimum requested length for variable-length GETMAlNs causes this 
second value to be exceeded, the job or job step abnormally terminates. For further 
information, see OS/VS2 System Programming Library: Job Management. 

Examples of the REGION Parameter 

//MKBOYLE EXEC A, ADDRSPC=REAL,REGION=40K 

40K of real storage is assigned to this job step. 

//STP6 EXEC PGM=CONT,REGION=120K 

A 120K region is assigned. For variable-length GETMAlNs, the request is satisfied as long as 
there remains in the region at least the minimum amount requested. If less than the minimum 
remains, the mmimum is allocated as long as the allocation does not cause the second limiting 
value (described above) to be exceeded. For fixed-length GETMAlNs, the amount requested is 
allocated as long as the allocation does not cause the second limiting value to be exceeded. 
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The TIME Psar&meter— keyword, optional 



The TIME parameter specifies the maximum amount of time that a job step can use the CPU. 
The CPU time used is written on the output listing. 



\i 



TIME= jj{ [minutes] [, seconds] )i 
1440 I 



minutes 

specifies the maximum number of minutes the job step can use the CPU. The number of 

minutes must be less than 1440 (24 hours). 
seconds 

specifies the maximum number of seconds beyond the specified number of minutes the job 

step can use the CPU. The number of seconds must be less than 60. 
1440 

specifies that the job step is not to be timed. 

I Default: defined by your installation in JES2 or JESS initialization parameters. The IBM default 
is 30 minutes. 



Rules for Coding 



If you code the CPU time limit in minutes only, you need not code the parentheses. 

Code 1440 if the job step can use the CPU for 24 hours or more or if the job step should 

be allowed to remain in a wait state for more than the estabhshed time limit. 

You can code the TIME parameter on the EXEC statement of a cataloged procedure step. ■ 

To override all TIME parameters in a cataloged procedure, code the TIME parameter on the 

EXEC statement that calls the procedure. This establishes a CPU time limit for the entire 

procedure, and nullifies any TIME parameters that appear on EXEC statements in the 

procedure. 

To override only certain TIME parameters, code, on the EXEC statement that calls the 

procedure, TiME.procstepname, for each procedure step that you want to override. The CPU 

time limit will then pertain only to the named procedure step. 

The remaining job time may affect the amount of time the step can use the CPU. If the 

remaining CPU time for the job is less than the CPU time limit specified on the EXEC 

statement, the step can use the CPU only for the job's remaining CPU time. 

A step that exceeds the specified limit causes termination of the job unless you use a user 

exit routine to extend the time. 

TlME=o is not supported. When coded on the EXEC statement, the step will fail only after 

the unexpired time from the previous step is used up. 
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Examples of the TIME Parameter 

//STEP1 EXEC PGM=GRYS,TIME=( 12,10 ) 

Specifies that the maximum amount of time the step can use the CPU is 12 minutes 10 
seconds. 

//FOUR EXEC PGM=JPLUS,TIME=( ,30) 

Specifies that the maximum amount of time the step can use the CPU is 30 seconds. 

//iNT EXEC PGM=CALC,TIME=5 

Specifies that the maximum amount of time the step can use the CPU is 5 minutes. 

//LONG EXEC PGM=INVANL,TIME=1440 

Specifies that the job step is not to be timed. Therefore, the step can use the CPU and can 
remain in a wait state for an unspecified period of time. 

//STP4 EXEC BILLING, TIME. PAID=( 45, 30), TIME. BILL=( 1 12,59) 

Specifies that different time limits pertain to each of the named procedure steps. 




EXEC 



TIME 



The EXEC Statement 173 



< 



174 OS/VS2 JCL {VS2 Release 3.7) 



Page of GC28-0692-2 
Revised May 28, 1976 
By TNL: GN28-2711 
VS2.03.810 



The DD Statement 



Control Statement 



The DD (data definition) statement describes a data set to be used in a job step and specifies 
the input and output faciUties required for the data set. 

/ //ddname DD operands comments 

The DD statement consists of the characters // in columns 1 and 2, and four fields — the 
name, operation (DD), operand, and comments field. 



General Rules for Coding 



• Code a DD statement for each data set to be used in a step. 

• Code a ddname, beginning in column 3, and consisting of 1 through 8 alphameric and 
national ((§),#,$) characters. The first character must be alphabetic or national. 

• Code unique ddnames within a job step. Under JES2, if duplicate ddnames exist in a step, 
allocation of devices and space and disposition processing are done for both DD statements; 
however, all references are directed to the first such DD statements in the step. Under JES3, 
if duplicate ddnames exist in a step, the job is abnormally terminated during allocation. 

• Apart from the restricted use of certain special ddnames (listed below), there are two 
instances when you should not code a ddname at all: 

• A DD statement is to define a data set that is concatenated with a data set defined by a 
preceding DD statement. 

• The DD statement is the second or third consecutive DD statement that defines an 
indexed sequential data set. 

• Special ddnames: Do not use the following seven special ddnames unless you wish to make 
use of the particular facilities which these names represent to the system; these facilities are 
explained in detail in the following pages. 

JOBCAT SYSABEND 

JOBLIB SYSUDUMP 

STEPCAT SYSCHK 
STEPLIB 

Under JES3, the following ddnames are reserved and should not be used on a DD statement: 




JCBIN 


JCLIN 


JESMSG 


JCBLOCK 


JESInnnn 


JOURNAL 


JCBTAB 


JESJCL 


SYSMSG 



Although all DD statement parameters are optional, a blank operand field is invalid, except 

when you are overriding DD statements that define concatenated data sets. 

The maximum number of DD statements allowed per job step is 1635. 

There are two types of parameters that can be coded on a DD statement: keyword and 

positional. The positional parameters, which must precede any ke5rword parameters, are: 



DATA 








DUMMY 






DYNAM 








The keyword parameters are: 




AMP 


DEST 


FREE 


SPACE 


BURST 


DISP 


HOLD 


SYSOUT 


CHARS 


DLM 


LABEL 


TERM 


CHKPT 


DSID 


MODIFY 


UCS 


COPIES 


DSNAME 


MSVGP 


UNIT 


DCB 


FCB 


OUTLIM 


VOLUME 



DDNAME FLASH 



QNAME 
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Rules for Coding when Using Cataloged Procedures 

• If a job step uses a cataloged procedure, you can make modifications to tlie DD information 
within the procedure for the duration of the job step. To do this, code modifications on the 
DD statements immediately following the EXEC statement that calls the cataloged procedure. 

• To override parameters on a DD statement within a cataloged procedure, code the name of 
the procedure step in which the DD statement appears, followed by a period, followed by 
the name of the DD statement that you want to override. 

• To override two or more DD statements in a procedure step, the sequence of the overriding 
statements must be the same as the sequence of the procedure statements being overridden. 

• To add DD statements to a procedure step, code the name of the procedure step in which 
the DD statement appears, followed by a period, followed by a ddname of your choosing. 
Added statements must follow all overriding statements. 

• To supply a procedure step with data in the input stream, code the name of the procedure 
step that is to use the data, followed by a ddname. This ddname may be predefined in the 
procedure step by means of the DDNAME parameter. In this case, the ddname that follows 
the procedure step name must be the name code in the DDNAME parameter. 

• Do not use a JOBLIB DD statement in a cataloged procedure. 

Examples of Valid Ddnames 

//INPUT DD DSN=FGLIB,DISP=( OLD, PASS ) 
// DD DSN=GR0UP2,DISP=SHR 

Because the ddname is missing from the second DD statement, the data sets defined in these 
statements will be concatenated. 

//PAYROLL . DAY DD 

If the procedure step named PAYROLL includes a DD statement named DAY, this statement 
will override parameters on the statement named DAY. If the step does not include a DD 
statement named DAY, this statement will be added to the procedure step for the duration of 
the job step. 

//STEPSIX.DD4 DD 
// DD 

This sequence defines data sets that are to be concatenated and added to the procedure step. 
On the first DD statement, the procedure step to which statements are to be added is identified 
and followed by any vaUd ddname. On the second DD statement, the ddname is omitted. 



I 



i 
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The JOBCAT FaciUty 



DD statement 



The JOBCAT DD Statement defines a private user catalog that is searched for data sets before 
the master catalog or a private catalog associated with the first qualifier of data set names for 
the duration of a job. 

//JOBCAT DD DISP= j OLD LDSNAME=usercatalognaine 



(OLD ),] 
iSHR\ 




Rules for Coding 

• JOBCAT applies to each job step in which a STEPCAT has not been specified. 

• The location of the user catalog is given in the master catalog, so do not specify any unit or jobcat 
volume information. 

• To specify more than one user catalog for a job, include after the JOBCAT statement an 
unlabeled DD statement that names another user catalog. 

• OS CVOLs cannot be specified as JOBCAT. Access to an OS CVOL is only possible with a 
CVOL pointer in the master catalog. 

• The JOBCAT statement must appear after the JOB statement, but before the first EXEC 
statement, 

• A JOBLIB statement must precede the JOBCAT statement, if specified. 

Example of the JOBCAT DD Statement 

The following example specifies a private user catalog. Place a JOBCAT DD statement before 
the first EXEC statement after the JOB statement. The JOBCAT DD statement should also 
appear after any JOBLIB statements. 



//EXAMPLE 


JOB 


WILLIAMS , MSGLEVEL= 1 


//JOBLIB 


DD 


DSNAME=USER . LIB , DISP=SHR 


//JOBCAT 


DD 


DSNAME=LYLE , DISP=SHR 


// 


EXEC 


PGM=SCAN 
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The JOBLIB Facility 



DD statement 



The JOBLIB DD statement defines a private library to be made available by the system to each 
step of a job. 

//JOBLIB DD 



General Rules for Coding 

• Code JOBLIB as the ddname on the first DD statement. Never use the ddname JOBLIB 
except to define a private library for an entire job. 

• Omit the ddname from all subsequent DD statements that define data sets that are to be 
concatenated to the first one. These DD statements must immediately follow the JOBLIB 
statement, and the JOBLIB statement must immediately follow the JOB statement. 

• If you include a JOBLIB DD statement in the JCL for a job, each time the job requests a 
program, the system first searches the private library; if it does not find the program there, 
it next searches the system library. 

• Use a STEPLIB DD statement, described under the STEPLIB FaciUty, to define a private 
library to be made available to one job step in a job. If you include a STEPLIB DD statement 
for a job step and a JOBLIB DD statement for the entire job, the system first searches the 
step library and then the system library for the requested program. The job library is 

ignored for that step. ■ 

• To make the private library available throughout the job, code the DISP parameter to specify 
the library's status and disposition. One of the following combination of DISP parameter 
values must be coded: 

DISP=(NEW,PASS) 

DISP=(OLD,PASS) 

DISP=(SHR,PASS) 

DISP=(NEW,CATLG) 

DISP=(OLD,CATLG) 

DISP=(SHR,CATLG) 

j For further explanation, see the discussion of the DISP parameter. 

• The rules for coding parameters on the JOBLIB DD statement depend on whether or not the 
private library is cataloged. These rules are discussed below under separate headings. 

• Do not use a JOBLIB statement in a cataloged procedure. 

• If COND=ONLY is specified on the first job step and a JOBLIB is being used, the unit and 
volume information are not passed to the succeeding step and the catalog will be searched 
for the JOBLIB data set. 

Rules for Coding When the Library is Cataloged 

• Code the DSNAME parameter to specify the name of the private library. 

• Code the DiSP parameter. The DISP parameter must be other than NEW. 

• Do not code VOL=SER to request a cataloged data set. 

• Code the DCB parameter if complete data control block information is not contained in the 
data set label. 

• To refer to the private library in a later DD statement, code DSNAME=*. JOBLIB and the 

DISP parameter. m 
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If a later DD statement defines a data set that is to be placed on the same volume as the 
private library, code VOLUME=REF=*,JOBLlB to obtain volume and unit information. 

Rules for Coding When the Library is Not Cataloged 

• Code the DISP parameter. The DISP parameter must be one of the following values: 

DISP=(OLD,PASS) 
DISP=(SHR,PASS) 
DISP=(NEW,PASS) 

• Code the unit parameter to specify the device to be allocated to the library. 

• Code the DSNAME parameter unless the data set has been assigned a disposition of 
(NEW.PASS). 

• Code the VOLUME parameter unless the status of the data set is NEW. 

• If the status of the data set is NEW, you must code the SPACE parameter to allocate space 
for the data set on the designated volume. 

• Code the DCB parameter if complete data control block information is not contained in the 
I data set label or in the problem program. 

• To refer to the private library in a later DD statement, code 
DSNAME=*.JOBLlB,vOLUME=REF=*.JOBLlB (or VOLUME =SER= serial number, UNIT=umt 
information), and the DISP parameter, DlSP=(OLD,PASS). 

If a later DD statement defines a data set that is to be placed on the same volume as the 
private library, code VOLUME =REF=*.J0BLIB to obtain volume and unit information. 

Examples of the JOBLIB DD Statement 

JONES, CLASS=C 

DSNAME=PRIVATE . LIB4 , DISP=( OLD , PASS ) 

PGM=SCAN 

PGM=UPDATE 

DSNAME=* . JOBLIB , DISP=( OLD , PASS ) 

The private library defined on the JOBLIB DD statement is cataloged. The statement named 
DDl refers to the private library defined in the JOBLIB DD statement. 

FOWLER, CLASS=L 

DSNAME=PRI V . DEPT58 , DISP=( OLD , PASS ) , 

UNIT=23 1 4 , VOLUME=SER=D58PVL 

PGM=DAY 

PGM=BENEFITS 

DSNAME=* . JOBLIB , VOLUME=REF=* . JOBLIB , 

.DISP=( OLD, PASS) 

The private library defined on the JOBLIB DD statement is not cataloged. The statement named 
DDl refers to the private library defined in the JOBLIB DD statement. 

MSGLEVEL=( 1,1) 

DSNAME=GR0UP8 . LEVELS , DI SP= ( NEW , CATLG ) , 

UNIT=23 1 4 , V0LUME=SER=1 48562 , 

SPACE=(CYL,(50,3,4) ) 

PGM=DISC 

DSNAME=GR0UP8 . LEVELS ( RATE ) , DISP=MOD , 

VOL=REF=*. JOBLIB 

PGM=RATE 

The private library defined on the JOBLIB DD statement does not exist yet; therefore, all the 
parameters required to define the private hbrary are included on the JOBLIB DD statement. The 
library is not created until STEPl when a new member is defined for the library. The system 
looks for the program named DISC in SYSLLINKLIB; the system first looks for the program 
named RATE in the private library. 
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//PAYROLL 


JOB 


//JOBLIB 


DD 


//STEPl 


EXEC 


//STEP2 


EXEC 


//DDl 


DD 



//PAYROLL 


JOB 


//JOBLIB 


DD 


// 




//STEP 


EXEC 


//STEP2 


EXEC 


//DDl 


DD 


// 





//TYPE 


JOB 


//JOBLIB 


DD 


// 




// 




//STEPl 


EXEC 


//DDA 


DD 


// 




//STEP2 


EXEC 



//PAYROLL 


JOB 


//JOBLIB 


DD 


// 


DD 


// 


DD 


// 





LIEF,TIME=1440 

DSNAME=KRG . LIB 1 2 , DISP=( OLD , PASS ) 

DSNAME=GR0UP31 . TEST, DISP=( OLD, PASS ) 

DSNAME=PGMSLIB , UNIT=23 1 4 , 

DISP=( OLD , PASS ) , VOLUME=SER=34568 



f 



Several private libraries are concatenated. The system searches libraries for each program in 
I this order: KRG.LIB12, GR0UP3.1.TEST, PGMSLIB, SYSl.LINKLIB. 



< 
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The STEPCAT Facility 



DD statement 



The STEPCAT DD Statement defines a private VSAM user catalog that is searched for data sets 
before the master catalog or a private catalog associated with the first qualifier of data set 
names for the duration of a job step. 

///STEPCAT DD DISP= ^ OLD J ,DSNAME=usercatalogname 

}shr( 




BH 



Rules for Coding 

• A STEPCAT DD Statement can appear in any position among the DD statements for a job 

^^®P' JOBLIB 

• The location of the user catalog is given in the master catalog, so do not specify any unit or stepcat 
volume information, 

• To specify more than one user catalog for a job step, include after the STEPCAT statement 
an unlabeled DD statement that names another user catalog. 

• If you want to override the JOBCAT with the master catalog for a particular job step, code 
the following: 

//STEPCAT DD DISP=OLD,DSNAME=master catalog name 

• OS cvoLs cannot be specified as STEPCAT. Access to an OS CVOL is only possible with a 
special CVOL pointer in the master catalog. 

Example of the STEPCAT DD Statement 

The following example specifies a job-step user catalog named BETTGER by placing a DD 
statement with the ddname STEPCAT after the EXEC statement for the job step: 

// EXEC PR0C=SNZ12 

//STEPCAT DD DSNAME=BETTGER,DISP=SHR 
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The STEPLIB Facility 



DD Statement 



The STEPLIB DD statement defines a private library to be made available by the system to a 
job step. 

//STEPLIB DD 



General Rules for Coding 

• The ddname on this statement must be STEPLIB. Never use the ddname STEPLIB except to 
define a private library for a job step. 

• A STEPLIB DD statement can appear in any position among the DD statements for a step. 

• A private library defined on a STEPLIB DD statement can be referred to by, or passed on to, 
later job steps in the same job. 

• If you include a STEPLIB DD statement in the JCL for a job, when the jobstep for which the 

I library is defined requests the program, the system first searches the private Ubrary; if it 
does not find the program there, it next searches the system library. 

• Use a JOBLIB DD statement, described under the JOBLIB Facility, to define a private library 
to be made available to an entire job. If you include a JOBLIB DD statement for the entire 
job and a STEPLIB DD statement for an individual job step, the system first searches the 
step library and then the system Ubrary for the requested program. The job library is 
ignored for that step. 

• A STEPLIB DD statement can appear in a cataloged procedure. 

• To concatenate libraries, that is, to arrange a sequence of DD statements that define 
different data sets: 

Code STEPLIB as the ddname of the first DD statement. 

Omit the ddname from aU subsequent DD statements that define private Ubraries for the 
particular step. 

• If you want the system to ignore the JOBLIB for a particular job step, use the following 
STEPLIB DD statement: 

//STEPLIB DD DSNAME=SYS1 .USERLIB,DISP=SHR 

For the particular job step, the system will first search the system library for the required 
data set. 

• The rules for coding parameters on the STEPLIB DD statement depend on whether the 
Ubrary is cataloged, not cataloged, or passed by a previous job step. These rules are 
discussed below under separate headings. 

Rules for Coding When the Library is Cataloged 

• Code the DSNAME parameter to specify the name of the private Ubrary. 

• Code the DISP parameter to specify the library's status and its disposition. Its status must be 
either OLD or SHR. Its disposition may be any vaUd disposition. 

• Code the DCB parameter if complete data control block information is not contained in the 
data set label. 
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Rules for Coding When the Library has been Passed by a Previous Step 

• Within a job, a previously defined step library must be made available for use by 
subsequent job steps by assigning a disposition of PASS. 

• To refer to a previously defined step library: 

Code the dsname parameter, specifying either the name of the step library or a backward 

reference of the form *.stepname.ddname. If the step library was defined in a cataloged 

procedure, the backward reference must include the procedure step name 

* .stepname.procstepname.ddname. 

Code the DISP parameter, specifying a status of OLD and a disposition, depending on what 

you want done with the private library after its use in the job step. 

Code the DCB parameter if complete data control block information is not contained in the 

data set label. 

Rules for Coding When the Library is Neither Cataloged Nor Passed 

• Code the dsname parameter, specifying the name of the private library. 

• Code the DiSP parameter, specifying the library's status, either OLD or SHR and a 
disposition, depending on what you want done with the private library after its use in the 
job step. 

• Code the VOLUME parameter, identifying the volume serial number. 

• Code the UNIT parameter, specifying the device to be allocated to the library. 

• Code the DCB parameter if complete data control block information is not contained in the 
data set label. 

Examples of the STEPLIB DD Statement 




//PAYROLL 


JOB 


BROWN, MSGLEVEL=1 


//STEP1 


EXEC 


LABI 4 


//STEP2 


EXEC 


PGM=SPKCH 


//STEPLIB 


DD 


DSNAME=PRIV . LIBS , DISP= ( OLD , KEEP ) 


//STEPS 


EXEC 


PGM=TIL80 


//STEPLIB 


DD 


DSNAME=PRIV.LIB13,DISP=(0LD,KEEP) 


The private libraries defined in STEP2 and STEP3 are cataloged. 


//PAYROLL 


JOB 


BAKER, MSGLEVEL=1 


//JOBLIB 


DD 


DSNAME=LIB5 . GR0UP4 , DISP=( OLD , PASS ) 


//STEP1 


EXEC 


PR0C=SNZ12 


//STEP2 


EXEC 


PGM=SNAP10 


//STEPLIB 


DD 


DSNAME=LIBRARYP,DISP=( OLD, PASS ) , 


// 




UNIT=23 1 4 , VOLUME=SER=55566 


//STEP3 


EXEC 


PGM=A1530 


//STEP4 


EXEC 


PGM=SNAP11 


//STEPLIB 


DD 


DSNAME=* . STEP2 . STEPLIB , 


// 




DISP=( OLD, KEEP) 



The private library defined in STEP2 is not cataloged. The STEPLIB DD statement in STEP4 
refers to the library defined in STEP2. Since a joblib dd statement is included, STEPl and 
STEPS could execute programs from LIB5.GROUP4 or, if the programs are not found there, 
from SYSI.LINKLIB. STEP2 and STEP4 could execute programs from libraryp or 

SYSl.LINKLIB. 
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THORNTON , MSGLEVEL= 1 

DSNAME=LIB5 . GR0UP4 , DISP=( OLD , PASS ) 

PGM=SUM 

DSNAME=SYS1 . LINKLIB,DISP=OLD 

PGM=VARY 

PGM=CALC 

DSNAME=PRIV. WORK, DISP=( OLD, PASS ) 

DSNAME=LIBRARYA, DISP=( OLD, KEEP ) , 

UNIT=2314,V0LUME=SER=44455 

DSNAME=LIB . DEPT88 , DISP=( OLD , KEEP ) 

PGM=SHORE 

STEP2 and STEP4 can use programs contained in the private library named LIB5.GROUP4, 
which is defined in the JOBLIB DD statement. STEPl can use a program from the system 
library, since the library defined on the STEPLIB dd statement is the system library. A 
concatenation of private libraries is defined in STEPS. The system searches for the program 
named CALC in this order: priv.work,librarya,lib.dept88,sysi.linklib. If a later job step 
refers to the STEPLIB dd statement in STEP3, the system will search for the program in the 
private library named priv.work, and if it is not found there, in sysI.linklib. 



//PAYROLL 


JOB 


//JOBLIB 


DD 


//STEPl 


EXEC 


//STEPLIB 


DD 


//STEP2 


EXEC 


//STEP3 


EXEC 


//STEPLIB 


DD 


// 


DD 


// 




// 


DD 


//STEP4 


EXEC 



i 



i 
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The SYSABEND and SYSUDUMP Facilities 



DD Statements 

The SYSABEND DD Statement defines a data set on which a dump can be written if the step in 
which the statement appears abnormally terminates. The dump provided by this facility 
includes the system nucleus, and the processing program storage area. 

The SYSUDUMP DD Statement defines a data set on which a dump can be written if the step 
in which the statement appears abnormally terminates. The dump provided by this facility 
includes only the processing program storage area. 

For information on how to interpret dumps, see OS/VS2 System Programming Library: 
Debugging Handbook. 

//SYSABEND DD STEPLIB 
//SYSUDUMP DD SYSABEND 
SYSUDUMP 




Rules for Coding 

• If you want to dump to a unit record device, code the UNIT parameter, specifying the unit 
record device to which you want to write the dump, or code the SYSOUT parameter, 
specifying the output class through which you want the data set routed. 

• If you want to store the dump and do not want it written immediately to any output device, 
code the following parameters: 

- The DSNAME parameter, specifying the name of the data set. 

- The UNIT parameter, specifying the device to be allocated to the data set. 

- The VOLUME parameter, identif3dng the serial number of the volume to which the dump 
is to be written. 

- The DISP parameter, specifying the data set's status and disposition. Since you want to 
store the data set, make the data set's conditional disposition KEEP or CATLG. 

- The SPACE parameter (for direct access devices), specifying the amount of space you 
want allocated to the data set. 

• If you are using the 3800 printer, and want a dump with 204 characters per line, code 
CHARS=DUMP. If you want a dump with 8 lines per inch, code FCB=STD3. Refer to the 
sections on the CHARS and FCB parameters for examples of requesting dumps with more 
data per page. 

Examples of the SYSABEND and SYSUDUMP DD Statements 

//STEP2 EXEC PGiyi=A 

//SYSUDUMP DD SYSOUT=A 

The SYSUDUMP DD statement specifies that you want the dump routed through the standard 
output class A. 

//SYSUDUMP DD DSNAME=DUMP,DISP=( NEW, KEEP ) , 
// UNIT=2400,VOL=SER=1 47958 

This step causes the dump to be stored on a standard labeled tape. 
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//STEPl 


EXEC 


//SYSABEND 


DD 


// 




//STEP2 


EXEC 


//SYSABEND 


DD 



PGM=PR0GRAM1 

DSNAME=DUMP , UNIT=23 1 4 , DISP=( , PASS , KEEP ) , 

VOLUME=SER=1234,SPACE=(TRK,( 40,20 ) ) 

PGM=PR0GRAM2 

DSNAME=* . STEP 1 . SYSABEND , DISP-( OLD , DELETE , KEEP ) 

The SYSABEND DD Statement specifies that you want the dump stored. The space request in 
STEPl is large (40 tracks or 340 maximum tracks) so that the dumping operation will not be 
inhibited due to insufficient space; if STEPl does not abnormally terminate but STEP2 does, 
the dump will be written using the space allocated in STEPl. In both steps, a conditional 
disposition of KEEP is specified. This will allow storing of the dump if either of the steps 
abnormally terminates. If both of the steps are successfully executed, the second subparameter 
of the DISP parameter (DELETE) in STEP2 will delete the data set and free the space acquired 
for dumping. 

PGM^WWK 

DSNAME=DUMP , UNIT=23 1 4 , DISP=( , DELETE , 

KEEP ) , VOLUME-SER=54366 , SPACE=( 1 680 , ( 1 60 , 80 ) ) 

PGM=PRINT , COND=ONLY 

DDNAME=* . STEPl . SYSUDUMP , DISP=( OLD , DELETE ) , 

VOLUME=REF=* . STEPl . SYSUDUMP 

Step 1 specifies that the dump is to be stored if the step abnormally terminates. Because 
COND=ONLY is specified in STEP2, the step will be executed only if STEPl abnormally 
terminates. STEP2 uses a program that prints the dump. 



i 



//STEPl 


EXEC 


//SYSUDUMP 


DD 


// 




//STEP2 


EXEC 


//IN 


DD 


// 





i 



i 
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The SYSCHK Facility 



DD Statement 

The SYSCHK DD Statement defines a checkpoint data set written during the original execution 
of a processing program. 

For detailed information about the checkpoint/restart facilities, see OS/VS 
Checkpoint/Restart. 

//SYSCHK DD 

General Rules for Coding 

• The SYSCHK DD statement must immediately precede the first EXEC statement of the 

SYSABEND 

resubmitted job when restart is to begin at a checkpoint. (If the first EXEC statement is sysudump 

preceded by a DD statement named SYSCHK and restart is to begin at a step, the SYSCHK syschk 
DD statement is ignored.) 

• The SYSCHK DD statement supports cataloged data sets. 

• Include a SYSCHK DD statement among the DD statements for a job whenever a deferred 
checkpoint restart is to occur, that is whenever a job is resubmitted for restart of execution 
at a particular checkpoint. 

• If you include a JOBLIB DD statement, the SYSCHK DD statement must follow it. 

• Code the RESTART parameter on the JOB statement; otherwise the SYSCHK DD statement 
will be ignored. 

• The rules for coding parameters on the SYSCHK DD statement depend on whether or not the 
checkpoint data set is cataloged. These rules are discussed below under separate headings. 

Rules for Coding When the Checkpoint Data Set is Cataloged 

If the checkpoint data set is cataloged, you must always code the DSNAME and DISP 
parameters. 

• The DSNAME parameter specifies the name of the checkpoint data set. 

• The DISP parameter must specify or imply a status OLD and a disposition of KEEP. 

• The UNIT parameter specifies the type and the number of devices assigned to the data set. 

• The VOLUME parameter specifies the volume(s) on which the data set resides. 

• If the checkpoint entry exists on a tape volume other than the first volume of the 
checkpoint data set, you must indicate this by coding the volume serial number or volume 
sequence number in the VOLUME parameter. (The serial number of the volume on which a 
checkpoint entry was written is contained in the console message printed after the 
checkpoint entry is written.) If you code the volume serial number, you must also code the 
UNIT parameter, since the system will not look in the catalog for unit information. 
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Rules for Coding When the Checkpoint Data Set is Not Cataloged I 

If the checkpoint data set is not cataloged, you must always code the dsname, disp, 
VOLUME, and unit parameters. 

• The DSNAME parameter specifies the name of the checkpoint data set. If the checkpoint 
data set is partitioned, do not include a member name in the DSNAME parameter. 

• The DISP parameter must specify or imply a status of OLD and disposition of keep. 

• The volume parameter specifies the volume serial number of the volume on which the 
checkpoint entry resides. (The serial number of the volume on which a checkpoint entry 
was written is contained in the console message printed after the checkpoint entry is 
written.) 

• The UNIT parameter specifies the device to be allocated to the data set. 

Example of the SYSCHK DD Satement 

//J0B1 JOB RESTART=(STEP3,CK3 ) 

//SYSCHK DD DSNAME=CHLIB,UNIT=2314, 

// DISP=OLD,VOLUME=SER=456789 

//STEP1 EXEC 

The checkpoint data set defined on the SYSCHK DD statement is not cataloged. 

//J0B2 JOB RESTART=( STEP2 , N0TE2 ) 

//JOBLIB DD DSNAME=PRI V. LIBS, DISP=( OLD, PASS) 

//SYSCHK DD DSNAME=CHECKPTS , DISP=( OLD , KEEP ) , 

// UNIT=2400,VOLUME=SER=438291 



//STEP1 EXEC 

The checkpoint data set defined on the SYSCHK DD statement is not cataloged. Note that the 
SYSCHK DD statement follows the JOBLIB DD statement. 



( 
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The * Parameter— pos/riona/, optional 



The * parameter specifies that data for a processing program follows the DD statement. The * 
parameter causes the system to check for an input delimiter (/*, //, or when the card reader 
runs out of cards or whatever you specify on the DLM parameter that overrides /*) on the 
input reader device. 

//ddname DD * 

General Rules for Coding 

You can code more than one DD * statement for each job step. 

Code the DATA parameter instead of the * parameter when the data contains statements 

starting with //. 

When preceding the data with a DD * statement, a delimiter statement (/*) following the 

data is optional. syschk 

You must code input stream data records in BCD or EBCDIC. 

If the processing program does not read all the data in an input stream, the remaining data 

is skipped without causing abnormal termination of the job. 

The DLM parameter can be used to define other than the standard delimiter. 

The DSID and the VOL=SER parameters can be used to indicate to a diskette reader that a 

diskette data set is to be merged into the JCL stream following this DD statement. 

Rules for Coding a Catalog Procedure 

• A cataloged procedure cannot contain a DD * statement. 

• If you call a cataloged procedure with the EXEC statement, you can include the data for 
each procedure step in the input stream. You can add more than one DD * statement to 
each procedure step. 

Restriction when Coding * 

• The keywords allowed on the DD * statement are: DLM, DCB=BLKSIZE, DCB=BUFNO, 
DCB=LRECL, VOL=SER, and DSID. All other keywords will cause an error. 

• The V0L=SER, DCB=BLKSIZE, DCB=BUFNO, DCB=LRECL, and DSID parameters are ignored 
except when they are detected by a diskette reader as a request for an associated data set as 
described in OS/VS2 IBM 3540 Programmer's Reference. 

Separating Groups of Data 

You can include several distinct groups of data in the input stream for a job step or a 
procedure step. The system wUl recognize each group of data if you precede each group with a 
DD * statement, or if you follow each group with a delimiter statement (/*), or both. (If you 
leave out the DD * statement for a group of data, the system provides a DD * statement 
having SYSIN as its ddname.) 
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Examples of the * Parameter 

//INPUT 1 DD 

data 



/* 
//INPUT2 



DD 



data 



/* 

Defines several groups of data in the input stream. 



//STEP2 
//SETUP . WORK 
//SETUP. INPUT 1 



EXEC 

DD 

DD * 



PROC=FRESH 
UNIT=2400,LABEL=( ,NSL) 



data 



/* 






//PRINT. FRM 


DD 


UNIT=180 


//PRINT. INP 


DD 


* 



data 



< 



/* 

Defines data in the input stream. The input data defined by the DD statement named 
SETUP. INPUT 1 is for use by the cataloged procedure step named SETUP; the input defined by 
the DD statement named PRINT. INP is for use by the cataloged procedure step named PRINT. 



//INPUT2 



DD 



data 



/* 

Defines data in the input stream. 
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The AMP Parameter — keyword, optional 



The AMP parameter completes information in an access method control block (ACB). The ACB 
is a control block for entry-sequenced, key-sequenced, and relative record data sets. 

For further information on AMP and the ACB, see OS/VS Virtual Storage Access Method 
(VSAM) Programmer's Guide. 

AMP= [AMORG] 

[ , ' BUFND=number ' ] 
[ , ' BUFNI=number ' ] 
[ , ' BUFSP=nuiTiber ' ] 

Crck") 
)nckI 
[ , ' crops= ) nre (' ] 
Inrc; 

[ , ' OPTCD= <L > • ] 

^F ^ AMP 

[ , ' RECFM= ) V ( • ] 

Ivb; 

[ , ' STRNO=number ' ] 

[ , ' SYNAD=modulename ' ] 

[, TRACE] 

AMORG 

indicates that the DD statement defines a vsAM data set. AMORG is required to open a DCB 
(through the ISAM interface program); however, it is not required to open an ACB for a 
VSAM data set. 

BUFND 

specifies the number of I/O buffers to be used for transmitting the contents of data control 
intervals between virtual and auxiliary storage. A minimum of two data buffers is required. 
If the number of buffers is not specified in the AMP parameter or the ACB or GENCB macro 
instructions, the default is the number specified for STRNO, plus one additional buffer. 

BUFNI 

specifies the number of I/O buffers to be used for transmitting the contents of index control 
intervals between virtual and auxiliary storage. A minimum of one index buffer is required. 
If the number of index buffers is not specified in the AMP parameter or ACB or GENCB 
macro instructions, the default is the number specified for STRNO. If the ISAM interface 
program is being used, a search of the high-level index in virtual storage can be simulated 
by adding one additional index buffer. 

BUFSP 

specifies the maximum size of the user area to be allocated for data and index buffers. If 
you specify less space than was specified in the BUFFERSPACE parameter of the DEFINE 
command of Access Method Services when the data set was defined, the BUFFERSPACE 
amount has precedence. 

CROPS 

specifies one of four checkpoint/restart options, described in OS/VS Checkpoint/Restart. 
RCK 

specifies that a data-erase test and data set post-checkpoint modification tests are 
performed. RCK is the default for CROPS. 
NCK 

specifies that data set post-checkpoint modification tests are not performed. 
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NRE 

specifies that a data-erase test is not performed. 
NRC 

specifies tliat neither a data-erase test nor data set post-checkpoint modification tests are 

performed. 
If no value for CROPS is specified, RCK is assumed. If you specify an option which is not 
applicable for a data set, such as the data-erase test for an input data set, the option is 
ignored. 

OPTCD 

specifies how records flagged for deletion are to be processed with an ISAM processing 

program using the ISAM interface. 

I 

specifies, when coded along with OPTCD=L in the DCB, that records marked for deletion 
by your processing program are not written into the data set by the ISAM interface. If 
OPTCD=l is specified in the AMP parameter, but OPTCD=L is not specified in the 
processing program's DCB, records flagged for deletion are treated like any other records; 
that is, AMP='OPTCD=r, with L not specified, has no effect. 
L 

specifies that a record marked for deletion by your processing program is to be kept in 
the data set. Although this parameter has the same meaning and restrictions for ISAM 
interface as it has for ISAM, it may have to be specified in the AMP parameter when it 
wasn't previously needed in the ISAM job control language. It is required when OPTCD=L 
is not specified in the DCB processing program because OPTCD is not merged into the 
DSCB when ISAM interface is used. 
IL 

Specifies that if the processing program marks a record for deletion, the ISAM interface 
does not put the record into the data set. 
RECFM 

specifies the ISAM record format that the processing program is coded for. Although this 
parameter has the same meaning and restrictions for the ISAM interface as it has for ISAM, 
it may have to be specified in the AMP parameter when it wasn't previously required in the 
ISAM job control language. RECFM is required when it is not specified in the DCB in the 
processing program because RECFM is not merged into the DSCB when the ISAM interface is 
used. All VSAM requests are for unblocked records. If your program issues a request for 
blocked records, the ISAM interface sets the overflow-record indicator for each record to 
indicate that each is being passed to your program unblocked. If RECFM isn't specified in 
the AMP parameter or in the processing program's DCB, V is the default. 
F 

indicates fixed-length records. 
FB 

indicates blocked fixed-length records. 

V 

indicates variable-length records. 
VB 

indicates blocked variable-length records. 
STRNO 

indicates the number of VSAM requests that require concurrent data set positioning. STRNO 
is an operand of the ACB or GENCB macro instruction and is fully described in OS/VS 
Virtual Storage Access Method (VSAM) Programmer's Guide. 



I 
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SYNAD 

is an operand of the EXLST macro instruction. It can be used to override the address of a 
SYNAD exit routine specified in the EXLST (or GENCB) macro instruction that generates the 
exit Ust. The address of the intended exit list is specified in the access method control block 
that links this DD statement to the processing program. If no SYNAD exit is specified, the 
AMP SYNAD parameter is ignored. 

You can also use this parameter when processing a VSAM data set with an ISAM processing 
program to provide an ISAM SYNAD routine or to replace one with another. 

TRACE 

specifies that the generalized trace facility (GTF) executes with your job to gather 
information about opening and closing of data sets, and end-of -volume processing. You can 
print the trace output with the AMDPRDMP program (see OS/VS2 System Programming 
Library: Service Aids). 



Rules for Coding 

• If the number of buffers specified in the BUFND and BUFNI subparameters causes the virtual 
storage requirements to exceed the BUFSP specification, the number of buffers is reduced to 
comply with BUFSP. If BUFSP specifies more space than required by BUFNO and BUFNI, the 
number of buffers is increased. 

• For a key-sequenced data set, the total minimum buffer requirement is three; two data 
buffers and one index buffer. For an entry-sequenced data set, two data buffers are 
required. 

• Apostrophes must enclose each subparameter or group of subparameters if they contain 
special characters, for example, AMP='BUFSP=value'. 

• If the subparameters continue from one line to another, each line of subparameters must 
begin and end with an apostrophe and the entire group of subparameters must be enclosed 
in parentheses. 

Additional rules for coding and further explanation of the AMP parameter are in the OS/VS 
Virtual Storage Access Method (VSAM) Programmer's Guide. 

Examples of the AMP Parameter 

//AMPDD DD DSN=SYS1 .MACLIB,DISP=SHR,AMP=( 'BUFSP=200,BUFND=2' , 

// 'BUFNI=3,STRNO=4,SYNAD=ERROR' ) 

Defines the size of the user area for data and index buffers; specifies the number of data and 
index buffers; specifies the number of requests that require concurrent data set positioning and 
specifies an error analysis routine. ERROR overrides the error analysis routine specified in the 
EXLST macro. 

//AMPDD DD DSN=SYS1 .MACLIB,DISP=SHR,AMP=( 'BUFSP=23456,BUFND=5' , 
// ' BUFNI= 1 , STRN0=6 , S YNAD=ERR0R2 , CROPS=NCK , TRACE ' ) 

Defines the values for BUFSP, BUFNI, STRNO, and SYNAD as in the previous example. It also 
specifies that a data-set-post-checkpoint modification test is not to be performed when 
restarting at a checkpoint and that OPEN is to provide a module trace. 

//AMPDD DD DSN=SYS1 .MACLIB,DISP=SHR,AMP=( 'BUFSP=23456' , 
// ' BUFND=5 ' , ' BUFNI= 10',' STRN0=6 ' , ' SYNAD=ERR0R2 ' , 

// ' CROPS=NCK ' , ' TRACE ' ) 

Another way of continuing subparameters from one line to another. 
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The BURST Parameter — keyword, optional i 



The BURST parameter specifies which stacker of the 3800 Printing Subsystem the paper output 
is to go to. If the stacker specified is different from that which was last requested, or if no 
previous request has been made, a message is printed on the system console telling the 
operator to thread the paper into the Burster-Trimmer-Stacker or the continuous forms stacker. 



BURST= 



\l\ 



Y 

indicates that the printed output is to be burst into separate sheets. 
N 

indicates that the printed output is to be in continuous, fanfold mode. 

Defatlt: If using SYSOUT, default is supplied by the subsystem handling the output. If not 
using SYSOUT, default is N. 

Rules for Coding 

• The BURST parameter can be specified on a SYSOUT DD statement when the 3800 is 
allocated as a system output device or on an output DD statement when the 3800 is 
allocated as a direct output device. 

• The Burster-Trimmer-Stacker can also be requested on the STACKER parameter of the JES3 
FORMAT PR Statement or the BURST parameter of the JES2 OUTPUT statement. 

• Refer to Figure 24 for parameters that are mutually exclusive with BURST. 

Example of the BURST Parameter 

//RECORD DD SYSOUT-A,BURST=Y 

Requests that the paper output be sent to the Burster-Trimmer-Stacker of the 3800 Printing 
Subsystem. The printed output is separated into individual sheets instead of being stacked in 
continuous, fanfold mode. 
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The CHARS Parameter — keyword, optional 



The character sets in the 3800 Printing Subsystem are used by means of character arrangement 
tables. The CHARS parameter specifies the name or names of character arrangement tables for 
printing a data set with the 3800. 

Figure 28 A gives the names of character arrangement tables supplied with the 3800, 
including those corresponding to print train names of IBM impact printers. For further 
information on character arrangement tables, see the section, "Writing Output Data Sets" for 
either JES2 or JES3, and the IBM 3800 Printing Subsystem Programmer's Guide. Refer to OS/VS2 
System Programming Library: System Generation Reference for information on how to choose, at 
SYSGEN time, the particular groups (other than the Basic group, which is always available). 

CHARS=( table name [, table name...] ) 

table name burst 

name of the character arrangement table (1-4 alphameric or national characters). chars 

General Rules for Coding 

• The CHARS parameter can be specified on a SYSOUT DD statement when the 3800 is 
allocated as a system output device or on an output DD statement when the 3800 is 
allocated as a direct output device. 

• From 1 to 4 table names can be specified on the CHARS parameter. 

• Null positions in the CHARS operands are tnvaUd. 

• Parentheses are not needed when one table name is coded. 

• CHARS can also be coded on the JES3 FORMAT PR statement or the JES2 OUTPUT statement. 

• Refer to Figure 24 for parameters that are mutually exclusive with CHARS. 

Requesting a High-Density Dump 

• In order to request a high-density dump, specify CHARS=DUMP on the dump-related DD 
statement. This wUl result in 204-character print lines. 

• You can also request dump output at 8 lines per inch by coding FCB=STD3. This can be 
coded on the same DD statement with CHARS=DUMP, or independently. 

• DUMP must be the first table specified if more than one table is coded on the CHARS 
parameter. 

Examples of the CHARS Parameter 

//DD1 DD SYSOUT=A,CHARS=(GS10,GU12 ) 

Specifies two character arrangement table names that can be used when printing a data set. 
GSiO refers to a Gothic character set, GU12 refers to a Gothic-underscored character set. 

//SYSABEND DD UNIT=3800 , CHARS=DUMP, FCB=STD3 

Requests a high-density dump at 8 Unes per inch and 204 characters per Une. 
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The CHKPT Parameter— it^>wn/, optional ^ 



The CHKPT parameter is used to invoke the checkpoint at end-of -volume facility. It specifies 
that checkpoints are to be taken for the data set defined by the DD statement on which it is 
coded. For more information, see OS/VS Checkpoint/Restart. 

CHKPT=EOV 
EOV 

specifies that checkpoints are to be taken at end of volume for that data set. 

Rules for Coding 

• The CHKPT parameter is specified only for multi-volume data sets using QSAM or BSAM. 
(CHKPT is ignored for non-multivolume QSAM or BSAM data sets or for ISAM, BDAM, BPAM, 
or VSAM data sets.) 

• Checkpoints can be taken on either input or output data sets. 

• For concatenated BSAM or QSAM data sets, CHKPT must be coded on each DD in the 
concatenation if checkpoint is desired for each DD. 

• If this parameter is specified on one or more DD statements in a job step, a SYSCKEOV DD 
must be provided (as outlined in the discussion on SYSCKEOV in OS/VS Checkpoint/Restart. 

• The RD parameter values NC and RNC on the JOB or EXEC statements override the CHKPT 
parameter. 

• The CHKPT parameter overrides cataloged procedure values or START console values for ^ 
checkpoints at end of volume. " 

• Refer to Figure 24 for parameters that are mutually exclusive with CHKPT. 

Examples of the CHKPT Parameter 

//DS1 DD DSNAME=INDS,DISP=OLD,CHKPT=EOV, 

// UNIT=SYSSQ,VOLUME=SER=(TAPE01 , TAPED 2 , TAPED 3 ) 

INDS is a multivolume QSAM (or BSAM) data set for which a checkpoint is to be taken 
twice — once after end of volume on TAPEOl and once after end of volume on TAPE02. 

//DS2 DD DSNAME=OUTDS,DISP=( NEW, KEEP), 

// CHKPT=EOV, UNITES YSDA,VOLUME=( , , ,8 ) 

OUTDS is a multi-volume data set being created that will require eight volumes. Seven 
checkpoints will be taken at the end of volumes one through seven. 
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The COPIES Parameter — keyword, optional 



The COPIES parameter specifies the number of copies of the data set to be printed, and if 
printing is done on a 3800, optionally specifies how the copies are to be grouped. 

For further information on the use of the COPIES parameter, see "Obtaining Output" for 
either JES2 or JES3 in this manual. 

COPIES=( nnn[ ,( group value, group value... )] ) 

mm 

specifies the total number of copies of the data set to be printed, subject to an installation 
limit, nnn is ignored for the 3800 if group values are specified. 
group value 

describes the grouping of the printed copies for the 3800 printer only. Each group value 

specifies the number of copies of each page that are to be grouped together. (For example, chkpt 

a group value of 3 causes the first page of a data set to be printed three times before copies 

printing is started for the second page.) When group values are coded they override nnn. 

The total number of copies printed equals the sum total of the group values. 

Default for nnn: 1 

If the nnn parameter of COPIES is omitted or incorrectly coded, it defaults to 1 and a warning 
message is issued. 

General Rules for Coding 

• Except for JES3, nnn can range from 1 to 255. The maximum number of copies for JES3 is 
hmited to 254. 

• If the group value subparameter is not specified, the number of copies indicated by nnn is 
printed. The printed output is in page sequence for each copy. 

• Parentheses are not needed when only nnn is coded. 

• If you request copies of the entire job (on the JES2 JOBPARM statement) as well as 
additional copies of the data set (on the DD COPIES parameter), and if the data set is part 
of the job related output, you may receive a number of copies equal to the product of the 
two requests. 

• Number of copies can also be specified on the JES2 OUTPUT and JES3 FORMAT control 
statements. 

• Refer to Figure 24 for parameters that are mutually exclusive with COPIES. COPIES is also 
mutually exclusive with the AFF, SEP, SPLIT, and SUBALLOC subparameters. 

Rules for Coding Group Value 

• The group value subparameter is for the 3800 printer only. 

• Each group value can range from 1 to 255. 

• A maximum of eight group values can be coded on the COPIES parameter. Their sum total 
must not exceed 255. 

• A null group value, or a zero or null position within the sublist of group values, is invaUd. 
(For example, C0PIES=(5,) and COPIES=(5,(1,0,4)) are invalid.) 
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Restriction when Using UNIT Parameter 



i 



The COPIES parameter is normally used with the SYSOUT parameter. If, however, COPIES is 
coded on a DD statement with the UNIT parameter, nnn defaults to 1. If printing is done on a 
3800 and group values are specified, the number of copies printed is equal to the first group 
value. 

Examples of the COPIES Parameter 

//RECORD DD SYSOUT=A, COPIES=32 

Requests 32 copies of the data set defined by the DD statement named RECORD when printing 
on an impact or 3800 printer. 

//REC0RD2 DD SYSOUT-A,COPIES=( 0,(1,2)) 

When printing on an impact printer, one copy (the default for nnn) is printed and a warning 
message is issued. If the 3800 is used, three copies of the data set are printed in two groups. 
The first group contains one copy of each page. The second group contains two copies of each 
page. 

//RECORDS DD SYSOUT-A, COPIES={ 8 , ( 1 , 3 , 2 ) ) 

If the output device is a 3800, six copies of the data set are printed in three groups. The first 
group contains one copy of each page, the second group contains three copies of each page, 
and the last group contains two copies of each page. If the output device is not a 3800, eight 
separate copies are printed. 

//REC0RD4 DD UNIT=3800 , COPIES=( 1 , ( 2 , 3 ) ) g 

The 3800 printer prints two copies of each page, since the UNIT parameter is specified. ^ 



i 
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The DATA Psarsaaieter— positional, optional t 



The DATA parameter specifies that data for a processing program is to follow the DD 
statement. This data can contain statements with the characters // in columns 1 and 2. 

//ddname DD DATA 

General Rules for Coding 

• You can code more than one DD DATA statement for each job step. 

• Code the * parameter instead of the DATA parameter when the data does not contain 
statements starting with //. 

• You must code input stream data records in BCD or EBCDIC. 

• If the processing program does not read all the data in an input stream, the remaining data 
is skipped without causing abnormal termination of the job. 

• You must code a delimiter to end data in the input stream. Define this parameter as either 
/* or use the DLM parameter. 

• The DSID and VOL=SER parameters can be used to indicate to a diskette reader that a 
diskette data set is to be merged into the JCL stream following this DD statement. 



Rules for Coding a Catalog Procedure 

lent for the job step that calls a cataloged procedure, you can add 

i 



If you had an EXEC statement for the job step that calls a cataloged procedure, you can add 

more than one DD data statement to a procedure step. 

A cataloged procedure cannot contain a DD DATA statement. 



Restrictions when Coding DATA 



The keywords allowed on the DD DATA statement are: DLM, DCB=BLKSIZE, DCB=BUFNO, 
DCB=LRECL, VOL=SER, and DSID and DCB=MODE=C for JES3 only. All other keywords 
cause an error. 

The VOL=SER, DCB=BLKSIZE, DCB=BUFNO, DCB=LRECL, and DSID parameters are ignored 
except when they are detected by a diskette reader as a request for an associated data set as 
described in OS/VS2 IBM 3540 Programmer's Reference. 



Separating Groups of Data 



You can include several distinct groups of data in the input stream for a job step or a 
procedure step. Precede each group of data with a DD DATA statement and follow it with a 
delimiter statement (/*). The data contained between the DD DATA statement and the 
delimiter statement and the delimiter must not contain /* in columns 1 and 2. See the DLM 
parameter. 
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Examples of the DD DATA Parameter 

//INPUT DD DATA 

data 



/* 

Defines data in the input stream. 



//STEP2 


EXEC 


//PREP . DD4 


DD 


// 




// 




//PREP . INPUT 


DD 



data 



/* 
//ADD . IN 



DD 



PROC=UPDATE 

DSNAME=A . B . C , VOLUME=SER=D88 , 

UNIT=23 1 4 , SPACE=( TRK, (10,5)), 

DISP=( ,CATLG, DELETE) 

DATA 




DATA 



data 



/* 

Defines data in the input stream. The input defined by the DD statement name PREP. INPUT is 
for use by the cataloged procedure step name PREP. This data contains job control statements. 
The input defined by the DD statement named ADD. IN is for use by the cataloged procedure 
step named ADD. Since this data is defined by a DD * statement, it must not contain job 
control statements. 



//INPUT 



DD 



DATA 



data 



/* 

//INPUTS 



DD 



DATA 



data 



/* 



Defines several groups of data in the input stream. 
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The DCB Psarsaneter— keyword, optional | 



The DCB parameter is used to complete information in a data control block (DCB) about a data 
set at execution time. The data control block is originally constructed in a processing program 
by a DCB macro instruction. 

For further information on the formation of the data control block, see OS/VS Data 
Management Services Guide. 

DCB=(list of attributes) 

DCB=( /dsname \ 

\ * . ddname f 

A *.stepname.ddnaine ? [,list of attributes]) 

( * . stepname . procstepname . ddname ) 

list of attributes 

those DCB ke3rword subparameters that describe the data set and are needed to complete 

the data control block. The DCB keyword subparameters are Usted alphabetically in this 

section in the pages immediately following. 
dsname 

the name of a cataloged data set from which the system is to copy DCB information. The 

information is contained in the data set label of the cataloged data set; the data set must 

reside on a direct access volume and the volume must be mounted before execution of the 

job step. 
*.ddnaine 

the name of an earlier DD statement in the same job step from which the system is to copy 

DCB information. 
^.stepname.ddname 

the name of a DD statement (ddname) in a earlier job set (stepname) from which the 

system is to copy DCB information. 
*.stepname.procstepname.ddname 

the name of a DD statement (ddname), which appears in a procedure step (procstepname); 

the procedure step is part of a cataloged procedure that was called by an earlier job step 

(stepname). 

General Rule for Coding 

Parentheses are not needed if only one keyword subparameter, a data set name, or a backward 
reference is coded. 

Completing the Data Control Block 

• You must code the DCB macro instruction in a processing program written in assembler 
language. However, some DCB operands (particularly those that may change from one 
execution of the program to the next) can be specified as DCB subparameters on a DD 
statement, or read from a data set label, or both. 

• If your processing program is written in a programming language other than assembler, DCB 
operands might be specified as part of file definition statments in your program, as DCB 
subparameters on a DD statement or data set label, or might be taken from 
language-defined defualt values via the DCB open exit routine. (Refer to the Programmer's 



Guide for your language to learn the alternatives open to you. Refer to OS/VS Data 
Management Services Guide for a description of the DCB open exit routine.) 



I 
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• You must code the DCB parameter on the DD statement if the data control block is not 
completed by your processing program, the data set label, or your languages's defined 
values. There are several ways of specifying DCB information on the DD statement. The 
following methods are explained in detail in the next three groups of syntax rules: 

• Suppl5ring all pertinent DCB keyword subparameters on the DD statement. 

• Copying the DCB information from the data set label of an existing cataloged data set. 

• Copying the DCB information from an earlier DD statement. 

Supplying DCB Keyword Subparameters 

• Code the information required to complete the data control block as keyword subparameters 
in the DCB parameter. 

• Separate DCB kejrword subparameters by a comma. 

• If the processing program and the DCB parameter supply the same subparameter, the 
subparameter on the DD statement is ignored. If the DCB parameter and the data set label 
supply the same subparameter, the subparameter on the data set label is ignored. 

• All DCB subparameters, except BLKSIZE, BUFNO, and DIAGNS are mutually exclusive with 
the DDNAME parameter. 

• The DCB ke3rword subparameters are listed alphabetically in this section in the pages 
immediately foUowing. 

Copying DCB Information From the Label of a Cataloged Data Set 

• You can copy DCB information from the data set label of a cataloged data set on a 
currently mounted direct access volume. A permanently resident volume is the most likely 
place from which to copy information because it is always mounted. 

• Code in the DCB parameter the data set name of the cataloged data set. The data set name 
cannot contain special characters, except for periods used in a qualified name. 

• The following DCB keyword subparameters can be copied from the data set label: 

DSORG (used in a backward reference) 

RECFM 

OPTCD 

BLKSIZE 

LRECL 

KEYLEN 

RKP 

The volume sequence number, system code, creation date, and expiration date of the 
cataloged data set will also be copied unless you specify them in the DD statement. 

• If you code any DCB keyword subparameters following the name of the cataloged data set, 
these subparameters override any of the corresponding subparameters that were copied. 

• The DCB subparameters are listed alphabetically in this section in the pages immediately 
following. 

Copying DCB Information From an Earlier DD Statement 

• The earlier DD statement from which DCB information can be copied can be contained in 
the same job step, an earUer job step, or an earlier cataloged procedure step. Code in the 
DCB parameter one of the following types of reference names, depending on the location of 
the DD statement you want to use: 

*.ddname 

* .stepname . ddname 

* .stepname. procstepname.ddname 

• If you code any DCB keyword subparameters following the reference to the DD statement, 
these subparameters override any of the corresponding subparameters that were copied. 
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The system copies only those subparameters from the earlier DD statement that are not 

again specified on the referencing DD statement. 

The UCS and fcb parameters are also copied from the earlier DD statement unless they are 

overridden by the referencing DD statement. 

The DCB subparameters are listed alphabetically in this section in the pages immediately 

following. 



Examples of the DCB Parameter 

DD 



//DD1 

// 

// 



DSNAME=ALP,DISP=( ,KEEP ) , VOLUME=SER=44321 , 
UNIT=2400 , DCB=( RECFM=FB , LRECL=240 , BLKSIZE=960 , 
DEN=1 ,TRTCH=C) 



Defines a new data set and contains the information necessary to complete the data control 
block. 



//DD2 

// 
//DD3 

// 



DD 



DD 



DSNAME=BAL , DISP=OLD , DCB=( RECFM=F , LRECL=80 , 
BLKSIZE=80 ) 

DSNAME=CNANN , DISP=( , CATLG , DELETE ) , UNIT=2400 , 
LABEL=( , NL ) , VOLUME=SER=663488 , DCB=* . DD2 



The statement named DD3 defines a new data set and requests the system to copy the DCB 
subparameters from the DD statement named DD2, which is in the same job step. 

//DD4 DD DSNAME=JST,DISP=( NEW, KEEP ),UNIT=2314, 

// SPACE=(CYL,( 12,2) ) ,DCB=( A.B.C,KEYLEN=8 ) 

Defines a new data set and requests the system to copy DCB information from the data set 
label of the cataloged data set named A.B.C.. If the data set label contains a key length 
specification, it is overridden since KEYLEN is coded on the DD statement. 



//DD5 DD DSNAME=SMAE,DISP=OLD,UNIT=2314, 
// DCB=( * . STEP 1 . PR0CSTP5 . DD8 , BUFN0=5 ) 

Defines an existing data set and requests the system to copy the DCB subparameters from the 
DD statement named DD8, which is contained in the procedure step named PR0CSTP5. The 
cataloged procedure was called by the job step named STEPi. If any of the DCB subparameters 
coded on the procedure DD statement have been previously defined for this data set, they are 
ignored. If the BUFNO subparameter has not been previously specified for the data set, then 
five buffers are assigned to the data control block. 

The following is a brief description of the DCB subparameters. For more detail on each of 
them, refer to the book describing the access method you are using. 

Access Method Publication 

BDAM, BISAM, SPAM, 
BSAM, QISAM, QSAM 

TCAM 

GAM 

EXCP 

BTAM 



OS/VS Data Management Macro Instructions, GC26-3793. 

OS/VS2 TCAM Programmer's Guide, GC30-2041. 

Graphic Programming Services for 2250, GC27-6971. 
Graphic Programming Services for 2260, GC27-6972. 

OS/VS2 System Programming Library: Data Management, 
GC26-3830. 

OS/VS BTAM, GC27-6980. 



i 
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Description of Subparameters 


BFALN 


X 


X 


X 


X 




X 




X 


X 




bfaln={f|d) 

Specifies that each buffer starts either on a word boundary that is not also 
a doubleword boundary or on a doubleword boundary. If both BFALN and 
BFTEK are specified, they must be supplied from the same source. 
Default: D (doubleword) 


BFTEK 


X 






X 


X 








X 




BFTEK=R (for BDAM and BSAM) BFTEK={s|e|a} (for QSAM) 
R specifies that the data set is being created for or contains variable-length 
spanned records. S, E, and A specify simple, exchange, or locate mode 
logical record interface for spanned records. It can only be coded when 
RECFM=VS. If both BFALN and BFTEK are specified, they must be 
supplied from the same source. 


BLKSIZE 


X 




X 


X 




X 




X 


X 


X 


BLKSIZE=number of bytes 

Specifies the maximum length, in bytes, of a block. The minimum length is 
18. The largest number allowed is 32,760 except for blocks of ASCII records 
on magnetic tape. This maximum length is 2048. If you code the BLKSIZE 
subparameter in the DCB macro instruction or on a DD statement that defines 
an existing data set with standard labels, the subparameter overrides the block 
size specified in the label. BLKSIZE may be coded but will have no effect on 
EXCP processing. 


BUFIN 




















X 


BUFIN-number of buffers 

Specifies the number of buffers to be assigned initially for receiving operations 

for each line in the line group. The number of buffers specified in the 

combined BUFIN and BUFOUT operands must be no greater than the number 

of buffers in the buffer pool for this line group (not including those for disk 

activity only). 

Default: 1 


BUFL 


X 


X 


X 


X 




X 




X 


X 


X 


BUFL=number of bytes 

Specifies the length, in bytes, of each buffer in the buffer pool. 

The maximum length allowed is 32,760. 


BUFMAX 




















X 


BUFMAX=number of buffers 

Specifies the maximum number of buffers to be allocated to a line at one time. 

The number must be greater than 1 but may not exceed 15. It must be at 

least equal to the larger of the numbers specified by the BUFIN and BUFOUT 

subparameters. 

Default: 2 


BUFNO 


X 


X 


X 


X 


X 


X 




X 


X 




BUFNO=number of buffers 

Specifies how many buffers are to be assigned to the DCB; the maximum 

normally is 255, but can be less because of the size of the partition or region. 


BUFOFF 








X 










X 




BUFOFF=(n|L) 

Specifies the buffer offset; that is, the length of an optional block prefix that 

can precede a block of one or more ASCI 1 records on magnetic tape. For 

input, n can be through 99, unsigned. For output, n can only be 0. 

L can be specified only when RECFM=D, indicating a four byte field 

containing block length. 


BUFOUT 




















X 


BUFOUT=number of buffers 

Specifies the number of buffers to be assigned initially for sending operations 

for each line in the line group. The combined number of BUFIN and BUFOUT 

values must not be greater than the number of buffer in the buffer pool for 

this line group (not including those for disk activity only) and cannot 

exceed 15. 

Default: 2 


BUFSIZE 




















X 


BUFSIZE=number of bytes 

Specifies the length, in bytes, of each of the buffers to be used for all lines in 
a particular line group. This length must be at least 31 bytes, but cannot 
exceed 65,535. 
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Description of Subparameters 


CODE 








X 




X 






X 




code={a|b|c|f|i|n|t} 

Specifies the paper tape code used for punched data. The subparameters 
CODE. KEYLEN, MODE, PRTSP, STACK, and TRTCH are mutually 
exclusive. 

A ASCII (8 track) 1 IBM BCD perforated tape 
B Burroughs (7 track) transmission code (8 track) 
C National Cash Register (8 track) N No conversion required 
F Friden (8 track) T Teletypei (5 track) 
Default: 1 


CPRI 




















X 


cpri={r|e|s} 

Specifies the relative transmission priority assigned to the lines in this line 

group. 

R Specifies that CPU receiving has priority over CPU sending. 

E Specifies that receiving and sending have equal priority. 

S Specifies that CPU sending has priority over CPU receiving. 


CYLOFL 
















X 






CYLOFL=number of tracks 

Specifies how many tracks on each cylinder are to hold the records that 
overflow from other tracks on that cylinder. The maximum is 99. 
Specify CYLOFL only when OPTCD=Y. 


DEN 








X 




X 






X 




DEN={0|l|2|3|4} 

Specifies the magnetic density in number of bits-| 

data set. 


3er-inch used to write a 




DEN 


7-track tape 


9-track tape 





1 
2 
3 
4 


200 
556 
800 


800 (NRZI) 
1600 (PE) 
6250 (GCR) 


Defa 


NRZI is for non-return-to-zero inverted recording mode. 
PE is for phase encoded recording mode. 
GCR is for group coded recording mode. 

ult: 800 bpi assumed for 7-track tape and 9-track without dual density. 
1600 bpi assumed for 9-track with dual density or phase-encoded 

drives. 
6250 bpi assumed for 9-track with 6250/1600 bpi dual density or 
group coded recording tape. 


DIAGNS 


X 


X 


X 


X 


X 


X 


X 


X 


X 




DIAGNS=TRACE 

Specifies the OPEN/CLOSE/EOV trace option which gives a module-by- 
module trace of OPEN/CLOSE/EOV's work area and the DCB. When GTF is 
not running and tracing user events, DIAGNS is ignored. 


1 Trademark of Teletype Corporation, Skokie, III. 



I 



i 
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Description of Subparameters 




parameters v^ 


03 


OQ 


m 


ffl 


Ul 


o 


o 


a 


t- 






DSORG 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


DSORG=data set organization 

Specifies the organization of the data set and indicates whether the data set 
contains any location-dependent information that would make the data set 
un movable. 




PS physical sequential data set. 


BSAM, EXCP, QSAM. TCAM 




PSU physical sequential data set that contains 


BSAM, QSAM, EXCP 


























location-dependent information. 




1 


DA direct access data set. 


BDAM, EXCP 




DAU direct access data set that contains 


BDAM, EXCP 


























location-dependent information. 




1 


IS indexed sequential data set. 


BISAM, QISAM, EXCP 




ISU indexed sequential data set that contains 


QISAM, EXCP 


























location-dependent information 






PO partitioned data set. 


BPAM, EXCP 




POU partitioned data set that contains 


BPAM, EXCP 


























location-dependent information. 






CX communications line group. 


BTAM 




GS graphic data control block. 


GAM 




TX TCAM line group data set. 


TCAM 




TQ TCAM message queue or checkpoint 


TCAM 


























data set 






EROPT 










X 








X 




EROPT=n 

BTAM: Requests the BTAM on-line terminal test option. n=T 
QSAM: Specifies the option to be executed if an error occurs in reading or 
writing a record. 

n=ACC system is to accept the block causing the error. 
SKP system is to skip the block causing the error. 
ABE system is to cause abnormal end of task. 
Default: ABE 




FRID 








X 














FRID=identifier 

Specifies a 1 to 4 character load module name identifying the first format 

record of the 3886 data set. FRID is mutually exclusive with the FCB 

parameter. 




FUNC 








X 










X 




func={i|r|p|w|d|x|t} 

Specifies the type of data set to be opened for the 3305/3525 card reader/ 

card punch. Unpredictable results will occur if coded with other than the 

3505/3525 devices. 

1 data in a data set is to be punched into and printed on cards. 

R data set is for reading cards. 

P data set is for punching cards. 

W data set is for printing. 

D data protection for a punch data set. 

X data set is for both punching and printing. 

T two-line print option. 

Default: output data set is P; input data set is R. 

The only valid combinations of these values are: 
i WT RWT RPWXT PWX 
R RP PW RPWD RPWX 
P RPD PWXT RWX RWX 
W RW RPW RWXT 




GNCP 














X 








GNCP=number of channel programs 

Specifies the maximum number of input/output macro instructions that will 

be issued before a WAIT macro instruction. 




INTVL 




















X 


INTVL={integer|0} 

Specifies the number of seconds of delay between passes through an 

invitation list. 

Default: 



^^a 



DCI 
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Description of Subparameters 


KEYLEN 


X 




X 


X 




X 




X 




X 


KEYLEN=number of bytes 

Specifies the length, in bytes, of the keys used in a data set. The largest 
number allowed is 255. The key length information can be supplied from the 
data set label for an existing data set. If a key length is not specified, no input 
or output requests that require a key can be used. 


LIMCT 


X 




















LIMCT=number of blocks or tracks 

Specifies how many blocks (if relative block addressing is used) or how many 
tracks (if relative track addressing is used) are to be searched for a free block 
or available space. This kind of search occurs only when the extended search 
option is specified (OPTCD=E); otherwise, LIMCT is ignored. If the number 
specified in the LIMCT subparameter equals or exceeds the number of blocks 
or tracks in the data set, the entire data set is searched. 


LRECL 






X 


X 




X 




X 


X 


X 


LRECL=number of bytes 

Specifies the length, in bytes, for fixed-length records or it specifies the 
maximum length, in bytes, for variable-length records. The length cannot 
exceed the blocksize (BLKSIZE) for U- or F- format records. It cannot 
exceed BLKSIZE-4 for V- or D- format records. For VS- format records, 
LRECL may exceed BLKSIZE. For unblocked records with a relative key 
position (RKP) of zero, the record length includes only the data portion of 
the record. The record length can be specified only when the data set is 
being created. 

LRECL may be coded but will have no effect on EXCP processing. 
OS AM: LRECL=X 

Specifies that the logical record length exceeds 32,760 bytes for variable- 
length spanned records. 


MODE 








X 




X 






X 




jc roll 

MODE= (E LrJ) 

Specifies the mode of operation to be used with a card reader, a card punch, 

or a card read-punch. 

C indicates card image (column binary) mode. 

E indicates EBCDIC mode. 

indicates optical mark read mode. 

R indicates read column eliminate mode. 

If R is specified then either C or E must be specified.' Do not code the MODE 

subparameter for data entered through the input stream except when using 

JESS. The subparameters MODE, CODE. KEYLEN, PRTSP, STACK, and 

TRTCH are mutually exclusive. 

Default: E 


NCP 




X 


X 


X 














NCP=number of channel programs 

Specifies the maximum number of READ or WRITE macro instructions that 

can be issued before a CHECK macro instruction is issued to test for 

completion of the I/O operation. The largest number that can be specified is 

99, but may be less depending on the size of the region or partition. If 

chained scheduling is used, NCP must be greater than 1 . 

Default: 1 


NTM 
















X 






NTM=number of tracks 

Specifies the number of tracks to be used for a cylinder index. When the 
specified number of tracks has been filled, a master index is created. This 
information is required only when the master index option (OPTCD=M) has 
been selected. If you omit NTM information and OPTCD=M is specified, the 
master index option is ignored. 
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Sub- 
parameters 



Access 
thod 



Description of Subparameters 



OPTCD 



Specifies the optionai services to ise performed by the control progranri. All 
optional services must be requested by one method, that is, by the data set 
label of an existing data set, the DCB macro, or the DD DCB parameter. 
However, it can be modified by the problem program. The characters may 
be coded in any order and when used in combination, no commas are 
permitted between characters. 



)=|iR» [E] [F] [W]/ 



BDAM: OPTCD="i(R» [E] [F] [W] 

A indicates that the actual device addresses are to be specified in READ and 

WRITE macro instructions. 
R indicates that relative block addresses are to be specified in READ and 

WRITE macro instructions. 
E indicates that an extended search (more than one track) is to be performed 

for a block or available space. (LIMCT must be coded but do not code 

LIMCT=0 because it will cause an ABEND when a READ or WRITE macro 

instruction is issued.) 
F indicates that feedback can be requested in READ and WRITE macro 

instructions and the device address returned is to be in the same form as 

that presented to the control program. 
W requests a validity check for write operations on direct access devices. 



BISAM: OPTCD={[L] [R] [W] } 

L requests that the control program delete records that have a first byte of 
all ones, (These records can be deleted when space is required for new 
records. To use the delete option, RKP must be greater than zero for 
fixed-length records and greater than four for variable-length records.) 

R indicates that relative block addresses are to be specified in READ and 
WRITE macro instructions. 

W requests a validity check for write operations on direct access devices. 



BPAM: 0PTCD={C|W|CW} 

C requests that chained scheduling be used. 

W requests a validity check for write operations on direct access devices. 



BSAM and QSAM: OPTCD= {b} 

{t} 

{U [C] } 

{C [THB]} 

{h [Z][B] } 

{j [C][U]} 

{W [C][T][B]} 

{Z [C][T][B] } 

{Q [C][T][B]} 

{z} 

B requests that the end-of-volume (EOV) routine disregard the end-of-file 
recognition for magnetic tape. For an input data set on a standard 
labeled (SL or AL) tape, the EOV routine treats EOF labels as EOV 
labels until the volume serial list is exhausted. This option allows SL or 
AL tapes to be read out of volume sequence or to be concatenated to 
another tape with the same data set name using one DD statement. 

C requests that chained scheduling be used. 

H requests hopper empty exit for Optical Readers or bypass of DOS 
checkpoint records. 

J for use with the 3800 Printing Subsystem — instructs the system that 
the first byte of each output data line (following the print control 
character) is a table reference character, which selects the character 
arrangement table corresponding to the order in which the table names 
have been specified on the CHARS parameter. For considerations 
before using OPTCD=J, see the IBM 3800 Printing Subystem 
Programmer's Guide. 

Q specifies that translation from ASCII input is required or that translation 
from EBCDIC to ASCII output is required. 

T requests user totaling facility. (T cannot be specified for a SYSIN or 
SYSOUT data set.) 



IHH 

DCB 



The DD Statement 205 



PageofGC28-0692-2 
Revised May 28, 1976 
ByTNL:GN28-2711 
VS2.03.810 



i 



Sub- 
parameters 



Access 
Method 
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OPTCD 
(continued) 



U only for 1403 or 321 1 printers with tlie Universal Cliaracter Set feature 
and the 3800; unblocks data checks and allows analysis by an appropriate 
error analysis routine. (If U is omitted, data checks are blocked, that is, 
not recognized as errors.) 

W requests a validity check for write operations on direct access devices. 

Z for nnagnetic tape input — requests the control program to shorten its 
nornrral error recovery procedure. When specified, a data check is 
considered permanent after five unsuccessful attempts to read a record, 
for direct access storage device input — specifies search direct (SD) for 
sequential data sets. 



BTAM and EXCP: 0PTCD=2 

Z for magnetic tape input — requests the control program to shorten its 
normal error recovery procedure. When specified, a data check is 
considered permanent after five unsuccessful attempts to read a record. 

BTAM Only: for direct access storage device input — specifies search direct 
(SD) for sequential data sets. 



QISAM: OPTCD={[l] [L] [M] [R] [U] [W] [Y]} 

I requests that ISAM use the independent overflow areas for overflow 

records. 
L requests that ISAM delete records that have a first byte 

of all ones. (These records can be deleted when space is required for new 

records. To use the delete option, RKP must be greater than zero for 

fixed-length records and greater than four for variable-length records.) 
M requests that the system create and maintain a master index(es) according 

to the number of tracks specified in the NTM subparameter. 
R requests that the control program place reorganization criteria information 

in certain fields of the data control block. (The problem program can 

analyze these statistics to determine when to reorganize the data set. 

This optioft is provided whenever the OPTCD subparameter is omitted 

from all sources.) 
U requests that the system accumulate track index entries in storage and 

write them as a group for each track of the track index. This can only be 

specified for fixed-length records. 
W requests a validity check for write operations on direct access devices. 
Y requests that the system use the cylinder overflow areas for overflow 

records. 



TCAM: 0PTCD={C|U|W} 

C specifies that one byte of the work area be used to indicate if a segment 

of a message is the first, middle, or last segment. 
U specifies that the work unit to be handled is a message. If U is omitted, 

the work unit is assumed to be a record. 
W specifies that the name of each message source is to be placed in an 

eight-byte field in the work area. 



PCI 



fN"! 


Hn" 


R 


,R 


A 


,A 


LxJ 


LxJ 



PCI=^ 



Specifies whether or not a program-controlled interruption (PCI) is to be used 
to control the allocation and freeing of buffers; the PCI subparameter also 
specifies how these operations are to be performed. The operands shown in 
the format above apply to receiving and sending operations, respectively. 
N specifies that no PCIs are taVen during filling (on receiving operations) 

or emptying (on sending operations) of buffers. 
R specifies that after the first buffer is filled or emptied, a PCI occurs during 

the filling or emptying of each succeeding buffer. The completed buffer 

is freed, but no new buffer is allocated to take its place. 
A specifies that after the first buffer is filled or emptied, a PCI occurs during 

the filling or emptying of the next buffer. The first buffer is freed and a 

buffer is allocated to take its place. 
X specifies that after a buffer is filled or emptied, a PCI occurs durino **^° 

filling or emptying of the next buffer. The first buffer is not fieed, but a 

new buffer is allocated. 

Parentheses are not needed if only the first operand is coded. 
Default: (A, A) 
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PRTSP 



PRTSP={0|l|2|3} 

Specifies the line spacing on a printer as 0, 1 , 2, or 3. It is valid only if the 
control characters A and M are not specified in the RECFM subparameter. 
The subparameters PRTSP, CODE, KEYLEN, MODE. STACK, and 
TRTCH are mutually exclusive. 

specifies that spacing is suppressed. 

1 specifies single spacing. 

2 specifies double spacing. 

3 specifies triple spacing. 
Default: 1 



RECFM 



BDAM: RECFM= 



Specifies the format and characteristics of the records in the data set. The 
format and characteristics must be completely described by one source; 
that is, the data set label of an existing data set, the DCB macro, or the 
DD DCB parameter. However, it can be modified by the problem program. 

V[S] f 
. [BS]( 

lF[T] ; 

U indicates that the records are of undefined length. 

V indicates that the records are of variable length. 

VS indicates that the records are of variable length, and spanned. 

VBS indicates that the records are of variable length, blocked and spanned 

and the problem program must block and segment the recprds. 
F indicates that the records are of fixed length. 

T indicates that the records may be written using the track-overflow feature. 
Default: undefined-length, unblocked records. ^^ 




U [T] 



n 


A 




M 


B 


A 


T 


M 


BT 




'B " 


"a" 


T 


M 


BT 





BPAM: RECFM= 



A indicates that the record contains American National Standards Institute 

control characters. 
B indicates that the records are blocked. 
F indicates that the records are of fixed length. 
M indicates that the records contain machine code control characters. 
T indicates that the records may be written using the track-overflow feature. 

Chained scheduling (OPTCD=C) will be ignored. 
U indicates that the records are of undefined length. 
V indicates that the records are of variable length. 
Default: U 
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RECFM 
(continued) 



r 



BSAM, EXCP, and QSAM: RECFM= -. 



um 



B 

S 

T 

BS 

BT 

BST 

B 

S 

T 

BS 

BT 

BST 



J 



For BSAM, EXCP, and QSAM using ASCII data sets on tape: 

/D[B][A]) 
RECFM= l\} [A] > 

If [b] [A]; 

A or M cannot be specified if the PRTSP subparameter is specified. 
A indicates that the record contains ANSI device control characters. 

indicates that the records are blocked. 

indicates that the records are variable-length ASCII tape records. 

indicates that the records are of fixed length. 

indicates that the records contain machine code control characters. 

for fixed-length records, the records are written as standard blocks, that 

is, no truncated blocks or unfilled tracks within the data set, with the 

exception of the last block or track. For variable-length records, a record 

can span more than one block. 
T indicates that the records can be written using the track-overflow feature 

if required. Chained scheduling (OPTCD=C) will be ignored. 
U indicates that the records are of undefined length. 
V indicates that the records are of variable length. Variable length records 

cannot be used for an ASCII tape data set or for a card reader data set. 

RECFM=V cannot be used for a 7-track tape unless the data conversion 

feature (TRTCH=C) is used. 
Default: U 



I 



QISAM: RECFM= (V [B] ) 
(F [B]) 

B indicates that the records are blocked. 

F indicates that the records are of fixed length. 

V indicates that the records are of variable length; variable length records 
cannot be in ASCII. When indexed sequential data sets are created, you 
can code the RECFM subparameter; when existing indexed sequential 
data sets are processed, FECFM must be omitted. 

Default: V 



TCAM: RECFM= 



{v IB,} 



B indicates that the records are blocked. 

F indicates that the records are of fixed length. 

U indicates that the records are of undefined length. 

V indicates that the records are of variable length. 

Default: U 



RESERVE 



RESERVE=(number1,number2) 

Specifies the number of bytes (from to 255) to be reserved in a buffer for 

insertion of data by the DATETIME and SEQUENCE macros. 

numberl indicates the number of bytes to be reserved in the first buffer tha 

receives an incoming message. 
number2 indicates the number of bytes to be reserved in all the buffers 

following the first buffer in a multiple-buffer header situation. 
Default: (0, 0) 



Vg 
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Description of Subparameters 


RKP 












X 






X 




RKP=number 

Specifies the position of the first byte of the record key within each logical 

record. The beginning byte of a record is addressed as 0. 

If RKP=0 is specified for blocked fixed-length records, the key begins in the 

first byte of each record, and the delete option (OPTCD=L) must not be 

specified. 

If RKP=0 is specified for unblocked fixed-length records, the key is not 

written in the data field; the delete option can be specified. 

For variable-length records, the relative key position must be 4 or greater, 

when the delete option (OPTCD=L) is not specffied. 

The relative key position must be 5 or greater if the delete option is specified. 

When indexed sequential data sets are created, you can code the RECFM 

subparameter; when existing indexed sequential data sets are processed 

RECFM must be omitted. 

Default: 

RKP can be coded but will have no effect on EXCP processing. 


STACK 








X 




X 






X 




STACK={l|2} 

Specifies which stacker bin is to receive a card. The subparameters STACK, 
CODE, KEYLEN, MODE, PRTSP, TRTCH are mutually exclusive. 
Default: 1 


THRESH 




















X 


THRESH=number 

Specifies the percentage of the non-reusable disk message queue records to be 

used before a flush closedown occurs. 

Default: closedown occurs when 95% of the records have been used. 


TRTCH 








X 




X 






X 




trtch={c|e!t|et} 

Specifies the recording technique for seven-track tape. The subparameters 

TRTCH, CODE, KEYLEN, MODE, PRTSP, and STACK are mutually 

exclusive. 

C specifies that the data conversion feature is to be used, with odd parity 

and no translation. 
E specifies even parity, with no translation and no conversion. 
T specifies that BCD to EBCDIC translation is required when reading, 

EBCDIC to BCD translation when writing; with odd parity and no 

data-conversion feature. 
ET specifies even parity and no conversion with BCD to EBCDIC or 

EBCDIC to BCD translation required. 
Default: odd parity with no translation or conversion. 
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The DDNAME Psffsaneter— keyword, optional 



The DDNAME parameter allows the postponing of defining a data set until later in the same 
job step. In the case of cataloged and in-stream procedures, this parameter allows you to 
postpone defining a data set in the procedure until the procedure is called by a job step. 

DDNAME=ddname 

ddname 

the name of the DD statement on which the data set is defined. 



General Rules for Coding 



Only the DCB subparameters DIAGNS, BLKSIZE, and BUFNO can be coded with the 

DDNAME parameter. If this subparameter is coded both on the DD statement that contains 

the DDNAME parameter and on the DD statement that actually defines the data set, the 

subparameter coded with the DDNAME parameter is ignored. 

You can code the DDNAME parameter up to five times in a job step or procedure step. 

However, each time the DDNAME parameter is coded, it must refer to a different ddname. 

If the data set, which will be defined later in the job step, is to be concatenated with other 

data sets, the DD statements that define these other data sets must immediately follow the 

DD statement that includes the ddname parameter. 

The ddname parameter cannot appear on a DD statement named JOBLIB, JOBCAT, or 

STEPCAT. 

The DDNAME parameter cannot refer to a DD statement that has DYNAM coded on it. 

If you postpone the definition of a data set by coding the DDNAME parameter, and then do 

not define the data set later in the job step, the job step is abnormally terminated. 

Refer to Figure 24 for parameters that are mutually exclusive with DDNAME. 



I 



Rules for Coding Backward References 



In any backward reference to a data set, you must use the ddname of the DD statement 
containing the DDNAME parameter, not the ddname specified in the DDNAME parameter. 
The DD statement that actually defines the data set cannot contain any backward references 
to a DD statement that follows the one with the DDNAME parameter. 
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//PROCSTEP 


EXEC 


//DDl 


DD 


//POD 


DD 



Example of the DDNAME Parameter 

The following procedure step is included in a cataloged procedure named CROWE: 

PGM= FLORA 
DDNAME=DAVE 
DSNAME=JEREMY , DISP=OLD 

The DD statement named DDl is meant to contain weekly records, in the form of data in the 
input stream, that are processed by this step. Since the * and DATA parameters cannot be 
included in cataloged procedures, the DDNAME parameter is used to postpone defining the 
data set' until the procedure is called by a job step. When calling the procedure, you would 
code: 

//STEPA EXEC CROWE 
//DAVE DD * 

data 
/* DDNAME 
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The DEST PsLrsaneter-— keyword, optional 



JES2 and JES3 allow you to route output to specified destinations. The DEST parameter 
specifies a remote destination (work station), a TSO user's location as the destination, a 
destination (central computing center), or a specific local device for an output data set. 

For further information on the DEST parameter, see "Obtaining Output" for either JES2 or 

JES3. 



JES2 


JES3 


Rnnn \ 


/ANYLOCAL 


RMnnn / 


} device-name 


RMTnnnf 


\ device-address 


Unnn / 


Vgroup-name 


LOCAL ^ 




name 7 





DEST= 



JES2 
Rnnn 
RMnnn 
RMTnnn 

where nnn is a 1-3 digit decimal number indicating the remote terminal to which the 
output data set is to be directed. 

Note: rO is equivalent to LOCAL. 
Unnn 

where nnn is a 1-3 digit decimal number (1-255) indicating the local device with special 
routing to which the output data set is to be directed. 

LOCAL 

a local device is the destination for the output data set. 
name 

1-8 alphameric or national character name of a remote or local device (as defined by the 
system programmer) to receive the output data set. 
JES3 

ANYLOCAL 

any device (either a printer or punch as defined by the output class on the DD statement) 
attached to the central CPU to received the output data set. 

device-name 

1 -8 alphameric or national character name of a local printer or punch (as defined by the 
system programming staff) to receive the output data set. 

device-address. 

three character physical device address of the device to receive the output data set. 
group-name 

name of a group of local devices, an individual remote station, or a group of remote 
stations to receive the output data sets. Specify LOCAL to define the default group-name 
for local devices (that is, those local devices that are in no other group). 

Default: name of the source of the job (whoever submitted the request). 
If the destination specified is invalid, the job fails. 
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Rules for Coding 



The DEST parameter can only be coded on a DD statement that includes the SYSOUT 
parameter. Otherwise, DEST is syntax-checked and ignored. 

Output destination can also be coded on the JES2 OUTPUT and ROUTE control statements 
and the JES3 MAIN ORG and FORMAT PR and PU DEST parameters. 




DEST 
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Example of the BEST Parameter 

//JOBO 1 JOB , ' REBECCA BARNHARDT ' , MSGLEVEL= 1 

//STEP1 EXEC PGM=INTEREST 

//DEB DD SYSOUT=A 

//GWB DD SYS0UT=A,DEST=RMT1 

The workstation from which the job was submitted receives the output described by the deb 
DD statement. The user identified by the station-id RMTl receives the output described by the 
GWB DD statement. 




DEST 
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The DISP Parameter — keyword, optional 



The DISP parameter describes the status of a data set to the system. It also indicates what is to 
be done with the data set after termination of the job step or job that processes it. You can 
indicate in the DISP parameter one disposition to apply if the step terminates normally after 
execution and another to apply if the step terminates abnormally (conditional disposition). For 
further information on the DISP parameter, see "Disposition Processing". 



DISP= 


NEW 
OLD 
SHR 
MOD 
_ / _ 




, DELETE 
,KEEP 
,PASS 
, CATLG 
, UNCATLG 




, DELETE 
,KEEP 
, CATLG 
, UNCATLG 








r 





Status 



Note: The disposition of a data set is solely a function of the DISP parameter; however, the 
disposition of the volumes on which the data set resides is a function of the volume status 
when the volume is demounted. 

NEW 

specifies that the data set is to be created in this job step. 
OLD 

specifies that the data set existed before this job step and that this step requires exclusive 

(non-shared) use of the data set. 
SHR 

Specifies that the data set existed before this job step and can be used simultaneously 
(shared) by another job, since it will only be read. 
MOD 

specifies that the read/write mechanism is to be positioned after the last record in the data 
set. If the system cannot find volume information for the data set, MOD specifies that the 
data set is to be created. 



specifies that NEW is assumed and that a normal or conditional disposition follows. 



Normal Termination Disposition 



DELETE 

specifies that the data set is no longer needed and its space on the volume is to be released 

at the end of this job step for use by other data sets if the data set has expired (see EXPDT 

or RETPD parameters). 
KEEP 

specifies that the data set is to be kept on the volume at the end of this job step. 
PASS 

Specifies that the data set is to be passed for use by a subsequent job step in the same job. 
CATLG 

specifies that the data set is to be kept at the end of this job step and an entry pointing to 

the data set is to be placed in the system or user catalog. Any missing index levels will be 

created. 



m 
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UNCATLG 

specifies that the data set is to be kept at the end of this job step but the entry pointing to 
the data set in the system or user catalog, and unneeded indexes, with the exception of the 
highest level, are to be deleted. 

specifies no explicit disposition for the data set, but indicates that a conditional disposition 
follows. A new data set is deleted and a data set that existed before execution of the job 
step is kept at step termination. 

Abnormal Termination (Conditional) Disposition 

DELETE 

specifies that the data set is no longer needed and its space on the volume is to be released 

for use by other data sets if this step abnormally terminates. 
KEEP 

Specifies that the data set is to be kept on the volume if this step abnormally terminates. 
CATLG 

specifies that an entry pointing to the data set is to be placed in the system or user catalog 

if this step abnormally terminates. Any missing index levels will be created. q,5P 

UNCATLG 

specifies that the entry pointing to the data set in the system or user catalog, and unneeded 

indexes, with the exception of the highest level, are to be deleted if this step abnormally 

terminates. 

Rules for Coding 

• Parentheses are not needed when only the first subparameter is specified. 

• If the data set is new, you can omit the subparameter NEW. However, if you specify a 
disposition or conditional disposition, you must code a comma to indicate the absence of 
NEW. 

• You can omit the DISP parameter if a data set is created and deleted during a job step. 

• If you do not want to change the automatic disposition processing performed by the system, 
you need not code the second subparameter. (When the second subparameter is not coded, 
the system automatically deletes data sets that did not exist before the job.) If you omit the 
second subparameter and code a conditional disposition, you must code a comma to indicate 
the absence of the second subparameter. 

• You must specify a disposition of PASS or DELETE for a temporary data set or a data set 
with a system-generated name; that is, when DSNAME=dsname or DSN=dsname is omitted 
from the DD statement. Any other disposition will be overridden by the system with PASS. 

• If a job step abnormally terminates and a conditional disposition is not specified, the normal 
disposition (second subparameter) is processed. 

• If a temporary data set name is specified, any conditional disposition other than DELETE or 
PASS is ignored. 

• If the data set name has special characters, you must not assign the CATLG disposition to it. 

• A data set can only be passed within a job. VSAM data sets cannot be passed. 

• If a job step abnormally terminates, conditional dispositions of CATLG, UNCATLG, or 
DELETE (of a cataloged data set) for unreceived data sets will not update a user catalog. 

• SHR can also be coded as SHARE. 

• Refer to Figure 24 for parameters that are mutually exclusive with DISP. 
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Examples of the DISP Parameter 



//DD2 
// 



DD 



DSNAME=FIX,UNIT=2400-1 , VOLUME=SER=44889 , 
DISP=(OLD, , DELETE) 

Defines an existing data set and implies that the data set is to be kept if the step terminates 
nonnally. (For an existing data set, the system assumes it is to keep the data set if no 
disposition is specified.) The statement requests that the system delete the data set if the step 
abnonnally terminates. 



I 



//STEP1 


EXEC 


//DD1 


DD 


// 




//STEP 2 


EXEC 


//DD2 


DD 


//DD3 


DD 


//STEPS 


EXEC 


//DD4 


DD 



PGM=FILL 

DSNAME=SWITCH . LEVEL 1 8 .GROUP 1 2 , UNIT=23 1 4 , 

VOLUME=SER=LOCAT3,SPACE=(TRK,(80, 15) ),DISP=( ,PASS) 

PGM=CHAR 

DSNAME=XTRA , DISP=OLD 

DSNAME=* . STEP 1 . DD1 , DISP=( OLD , PASS , DELETE ) 

PGM=TERM 

DSNAME=* . STEP2 . DD3 , DISP=( OLD , CATLG , DELETE ) 

The DD statement named DDl in STEPl defines a new data set and requests that the data set 
be passed. If STEPl abnormally terminates, the data set is deleted since it is a new data set and 
a conditional disposition was not specified. The DD statement named DD3 in STEP2 receives 
the passed data set and requests that the data set be passed. If STEP2 abnormally terminates, 
the data set is deleted because of the conditional disposition of delete. The DD statement 
named DD4 in STEP3 receives the passed data set and requests that the data set be cataloged at 
the end of the step. If steps abnormally teiminates, the data set is deleted because of the 
conditional disposition of DELETE. 
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The DLM FsLTsaneter—keyword, optional 



The DLM parameter allows you to use a delimiter other than /* to terminate data defined in 
the input stream. By assigning a different delimiter in the DLM parameter, you can include a 
standard delimiter (/*) as data in the input stream. 

DLM=delimiter 



delimiter 

specifies two characters that indicates the end of a group of data in the input stream. 

Default: /* 



m^MMM^ffV W MM^ 9 mmmM MMMMfi 



For JES2, if one character is specified, the default is used. If more than 2 characters are 

specified, the first 2 characters are used as the delimiter. For JES3, if an incorrect number of 

characters is coded, the job is flushed. 

The delimiter can be any two characters. 

If the delimiter contains special characters, enclose them in apostrophes. If you include an 

ampersand or an apostrophe in the delimiter, you must code each ampersand or apostrophe 

as two consecutive ampersands or apostrophes. Violating the special character coding rules 

produces unpredictable results. 

The DLM parameter has meaning only on statements defining data in the input stream (DD 

* and DD DATA statements). If DLM is specified on any other statement, a mutually 

exclusive error message is issued. 

If you do code the DLM parametei* on a DD DATA statement, the characters you assign as 

delimiters override any delimiter implied by the DD DATA statement. You must terminate 

the data with the characters you assigned in the DLM parameter. 

If the system encounters an error on the DD statement before the DLM parameter, it does 

not recognize the value assigned as a delimiter. When the card reader is emptied, the input 

reader device also causes the system to end an input data set. 

JES2 statements are not recognized if they are in an input stream between the DLM 

parameter and the nonstandard delimiter. 




DISP 
DLM 



Example of the DLM Parameter 

//DD1 DD *,DLM=AA 

data 



AA 

The DLM parameter assigns the characters AA as the valid delimiter for the data defined in the 
input stream by DDi. For JES2, the characters // would also serve as valid delimiters since a 
DD * statement was used. JES3 accepts only the characters specified for the DLM parameter as 
a terminator for DD * or DD DATA. 
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The DSID PsarsmieteT— keyword, optional | 



The DSID parameter specifies the data set identifier of an input or output data set on diskette 
for the 3540 diskette reader or writer utilities. Output data sets to be written to a 3540 
diskette must be assigned to an output class that is processed by the diskette writer (an 
external writer). For the diskette writer to receive data sets, reserved classes for diskette 
output must be defined. To write data sets on a diskette, the operator must start the diskette 
writer to a 3540 device. 

For more information about associated data sets, refer to the section, "Associated Data Sets 
(3540 Diskette)" in this book and to OS/VS2 IBM 3540 Programmer's Reference. 

DSID=(id, [V] ) 

id 

specifies the data set identifier. The identifier can be 1 - 8 characters in length. The 
characters must be alphameric, national, minus (hyphen), or left bracket (12-0 punch). The 
first character must be alphabetic or national. 

V 

specifies that the data set label must have been previously verified on a 3741 data entry 
terminal. (SYSIN only) 

Rules for Coding 

• Parentheses are not needed if only the id is coded. ■ 

• DSID on the DD * or DD DATA statement is ignored except when the JCL is processed by a 
diskette reader, 

• Along with DSID, you can specify volume serial and logical record length information on the 
DD * and DD DATA Statements. 

Refer to Figure 24 for parameters that are mutually exclusive with DSID. DSID can be 
specified with the DD *, DD DATA, and DD SYSOUT parameters; otherwise, it is ignored. 

Example of the DSID Parameter 

, ,MSGLEVEL=( 1,1) 

PGM=AION 

* , DSID={ ABLE , V ) , VOL=SER= 1 23456 , 

DCB=LRECL=80 

SYSOUT=E , DCB=LRECL= 128, DSID=BAKER 

The input is found on diskette 123456 in data set ABLE and must have been verified. The 
output will be created on diskette in data set BAKER, 



//J0B1 


JOB 


//STEP 


EXEC 


//SYSIN 


DD 


// 




//SYSPRINT 


DD 
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The DSNAME Par^aaieter— keyword, optional 




The DSNAME parameter specifies the name of a data set. For new data sets, the name 
specified is assigned to the data set; for existing data sets, the system uses the name to locate 
the data set on the volume. 

For further information on indexed sequential data sets and generation data groups, see, 
"Special Data Sets.". Partitioned data sets are described in OS/VS Data Management Services 
Guide. 

DSNAME i = / dsname 

DSN ) I dsname (member name) 

dsname ( generation number) 
I dsname (area name) 

SSdsname 

S£dsname( member name ) 

S£dsname( area name) 

*.ddname V DSID 

* . stepname . ddname ) DSNAME 

* . stepname . procstepname . ddname 

dsname 

specifies a data set name. 
dsname(member name) 

specifies a nontemporary partitioned data set name and the name of a member within that 

data set. 
dsname(generation nmnber) 

specifies the name of a generation data group (GDG) and the generation number (zero or a 

signed integer) of a generation data set within the GDG. 
dsDame(area name) 

specifies the name of a nontemporary indexed sequential data set and an area of that data 

set (INDEX, PRIME, or OVFLOW). 
&&dsname 

specifies the name of a temporary data set. 
&&dsname(member name) 

specifies the name of a temporary partitioned data set and a member within that data set. 
&&dsname(area name) 

specifies the name of a temporary indexed sequential data set and an area of that data set 

(INDEX, PRIME, or OVFLOW). 
^.ddname 

specifies that the data set name is to be copied for an earlier DD statement in the job step. 
"".stepname.ddname 

specifies that the data set name is to be copied from an earUer DD statement, ddname, 

which appears in an earlier step, stepname, in the same job. 
*.stepname.procstepname.ddname 

specifies that the data set name is to be copied from an earher DD statement in a cataloged 

procedure. Stepname is the name of the job step that calls the procedure, procstepname is 

the name of the procedure step that includes the named DD statement, and ddname is the 

name of the DD statement that contains the data set name. 
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General Rules for Coding f 

• The DSNAME parameter can be abbreviated DSN. 

• If the data set name begins with a blai^ character, the system assigns the data set a 
temporary data set name. Blank characters at the end of a data set name are ignored. 

I • Refer to Figure 24 for parameters that are mutually exclusive with DSNAME. 

Special Characters 

• If a data set name includes special characters as part of the name (the characters do not 
have special significance- to the system), you must enclose the name in apostrophes (5-8 
punch). If one of the special characters is an apostrophe, identify it by coding two 
consecutive apostrophes, for example, DSNAME= 'DAYS"END'. 

• If the only special character is a period or a hyphen, you need not enclose the data set 
name in apostrophes. 

• The following special characters have significance to the system and must not be enclosed in 
apostrophes: ampersands coded to identify temporary data sets; parentheses enclosing the 
member name of a partitioned data set, the area name of an indexed sequential data set, or 
the generation number of a generation data set; and the asterisk, used in the backward 
reference. 

• If a data set is to be cataloged, the data set name cannot contain special characters. 

Nontemporary Data Sets 

You can assign a nontemporary data set either an unqualified or qualified name. An unqualified 
name consists of 1 to 8 characters. The first character must be an alphabetic or national 
(@,#,$) character; the remaining characters can be any alphameric or national characters, a £- 

hyphen, or a plus zero (12-0) punch. A qualified name consists of multiple names joined by ■ 

periods. The rules for coding each name within a qualified name are the same as for coding an 
unqualified name. A qualified data set name can include as many as 44 characters^ including 
periods, unless the data set is a generation data set. Qualified names of generation data groups 
cannot exceed 35 characters, including periods. 

Temporary Data Sets 

• You need not code the DSNAME parameter when defining a data set that is created and 
deleted within a job (a temporary data set). The system wUl generate a name for the data 
set. 

• If you do code the DSNAME parameter, the data set name consists of 1 to 8 characters and 
is preceded by two ampersands ( & & ). The first character following the ampersands must 
be an alphabetic or national ((§),#,$) character; the remaining characters can be any 
alphameric or national characters, a hyphen, or a plus-zero (12-0) punch. The system 
generates a qualified name for the temporary data set that begins with SYS and includes the 
jobname, the temporary name assigned in the DSNAME parameter, and other identifying 
characters. 

• A single ampersand preceding a data set name in a cataloged or in-stream procedure 
normally signifies a sjrmbolic parameter. However, if no value is assigned to the name on 
either the EXEC statement that calls the procedure or on a PROC statement within the 
procedure, the name is treated as a temporary data set name. 
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Special Data Sets 

• An indexed sequential data set can be either temporary or nontemporary. If you use only one 
DD statement to define an indexed sequential data set, omit the area name or code PRIME 
for the area name; for example, DSNAME=dsname or DSNAME=dsname(PRiME). To 
retrieve an indexed sequential data set, code only the data set name and omit the area 
name. 

• If you assign a qualified name to a generation data group, the qualified name cannot exceed 
35 characters, including periods. To retrieve all generations of a generation data group, omit 
the relative generation number in the DSNAME parameter. 

Examples of the DSNAME Parameter 

//DDl DD DSNAME=ALPHA,DISP=( ,KEEP), 

// UNIT=2400,VOLUME=SER=389984 

Defines a new data set whose name is ALPHA. Later job steps or jobs may retrieve this data 
set by supplying the data set name in the DSNAME parameter, unit information in the UNIT 
parameter, and volume information in the VOLUME parameter. 

DSNAME 

//DD2 DD DSNAME=PDS(PR0G12 ),DISP=(OLD,KEEP),UNIT=2314, 

// VOLUME=SER=882234 

I Retrieves member PROG 12 from the partitioned data set named PDS. 

//DD3 DD DSNAME=SSWORK,UNIT=2400 

Defines a temporary data set. Since the data set is to be deleted at the end of the job step, the 
DSNAME parameter can be omitted. However, it may be included to facilitate a later reference 
to a passed data set; for example, DSNAME= & & W0RK,DISP=0LD, in which case you must 
add DISP=(,PASS) to DD3. 

PGM=CREATE 

DSNAME=S£ISDATA( PRIME ),DISP=( ,PASS ) ,UNIT=( 2311 ,2 ), 

SPACE=(CYL,( 10, ,2 ), ,CONTIG ) , V0LUME=SER=33489 , 

DCB=DSORG=IS 

PGM=OPER 

DSNAME=* . STEP 1 . DD4 , DISP=( OLD , DELETE ) 

The DD statement named DD4 in STEPl defines a temporary indexed sequential data set whose 
name is ISDATA. This DD statement is used to define all of the areas of an indexed sequential 
data set. The DD statement named DD5 in STEP2 retrieves the data set by referring to the 
earlier DD statement that defines the data set. Since the temporary data set will be passed 
when it is defined in STEP!, STEP2 can retrieve the data set. 



//STEPl 


EXEC 


//DD4 


DD 


// 




// 




//STEP2 


EXEC 


//DD5 


DD 
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n.e DUMMY P^«.eter-j.siHo„a, opHonat { 



The DUMMY parameter specifies that: 

• No device or external storage space is to be allocated to the data set. 

• No disposition processing is to be performed on the data set. 

• For BSAM and QSAM, no input or output operations are to be performed on the data set. 

For further information on the DUMMY parameter, see "Defining a Dummy Data Set." 

//ddname DD DUMMY 

Rules for Coding 

• Code the DUMMY parameter by itself or follow it with all the parameters you would 
normally code when defining a data set, except the DDNAME parameter. The DDNAME and 
DUMMY parameters are mutually exclusive. 

• Code the DCB parameter if you would code it for normal I/O operations. DCB information 
can be established in the DUMMY DD statement. 

• Code AMP=ORG if you are using VSAM and specify DUMMY for a data set. 

• If you used the DUMMY parameter to test a program, when you want input or output 
operations performed on the data set, replace the DD statement that contains the DUMMY 
parameter with a DD statement that contams all of the parameters required to define this 

data set. m 

• When nulUfying a procedure DD statement that contains the DUMMY parameter, code the ■ 
DSNAME parameter on the overriding DD statement. However, be sure that the data set 

name is not NULLFILE. Assigning the name NULLFILE in the DSNAME parameter has the 
same effect as code DUMMY. 

• If you code the DUMMY parameter and also request an access method other than the basic 
sequential access method (BSAM) or queued sequential access method (QSAM) to read or 
write the data set, or if the DUMMY parameter is coded and the access method of BDAM 
load mode (BSAM with DCB MACRF=WL) is requested, a programming error wUl occur. 

• Besides bypassing input or output operations on a data set, the DUMMY parameter causes 
the UNIT, SPACE, and DISP parameters, when coded on the DD DUMMY statement, to be 
ignored; however, these parameters are checked for syntax. 

• Backward references: If you code DUMMY on a DD statement and a later DD statement in 
the same job refers to this DD statement when requesting unit affinity (UNlT=AFF=ddname) 
or volume affinity (vOLUME=REF=*.stepname.ddname), the data set defined on the later 
DD statement will be assigned a dummy status. 

• Data sets concatenated to a DUMMY data set will also be treated as a DUMMY data set by 
the system. 

• If you use DD DUMMY and either VOL=REF=dsname or DCB=REF=dsname, the referenced 
dsname must be cataloged or passed or the job fails. 
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Examples of the DUMMY Parameter 

//OUTPUT DD DUMMY,DSNAME=X.X.Z,UNIT=2314, 
// SPACE=(TRK,( 10,2 ) ),DISP=( ,CATLG) 

Defines a dummy data set. The parameters coded with the DUMMY parameter is not used. 

//IN DD DUMMY,DCB=(BLKSIZE=800,LRECL=400,RECFM=FB) 

Defines a dummy data set. The DCB parameter supplies information that was not supplied in 
the DCB macro instruction for the data control block. Otherwise, abnormal termination may 
occur. 

If you are calling a cataloged procedure that contains the following DD statement in STEP4, 

//IN DD DUMMY,DSNAME=ELLN,DISP=OLD,VOL=SER=11257,UNIT=2314 

you can nullify the effects of the DUMMY parameter by coding: 

//STEP4.IN DD DSNAME^ELLN 

If you are calling a cataloged procedure that contains the following DD statement in STEPl, dummy 

//TAB DD DSNAME=APP.LEV12,DISP=0LD 

you can make this DD statement define a dummy data set by coding: 

//STEPl. TAB DD DUMMY 

If you are calling a cataloged procedure that contains the following DD statement in a 
procedure step named LOCK, 

//MSGS DD SYSOUT=A 

you can make this DD statement define a dummy data set by coding: 

//LOCK. MSGS DD DUMMY 
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The DYNAM Paiameter— positional, optional 

The DYNAM parameter specifies that a resource can be held in anticipation of reuse. 
For further information, see "Dynamically Allocating and Deallocating Data Sets." 

//ddname DD DYNAM 

Rules for Coding 

• Do not code any other parameters with the DYNAM parameter. 

• Do not use the DDNAME parameter to refer to a DD DYNAM statement. 

• To nullify the DYNAM parameter in a cataloged procedure, code the SYSOUT or DSNAME 
parameter in the overriding DD statement, but do not use the DSNAME=NULLFILE. 

• Coding DYNAM on DD statements that will require dynamic allocation no longer establishes 
this DD statement as a DUMMY request. Rather, the number of DYNAM requests are added 
to the DYNAMNBR value only to acquire a control value necessary to track the resources to 
be held for reuse. 

• Do not use any type of DD parameter referback to a DD DYNAM statement. 

• Do not code the DYNAM parameter on the first DD statement of a group of DD statements 
defining a data set concatenation. 

• Do not code the DYNAM parameter on a DD statement having a ddname that is meaningful 
to the system; for example, JOBLIB, SYSCHK, etc. 

Example of the DYNAM Parameter 

//INPUT DD DYNAM 

Specifies that the control value for dynamically allocated resources held for reuse is 
incremented by one for dynamic allocation. 
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The FCB Parameter — keyword, optional 



The FCB parameter specifies the forms control image to be used to print an output data set on 
a 3800 or 3211 printer, or the data protection image to be used for the 3525 card punch or 
for SYSOUT. 

For further information on the forms control buffer, see OS/VS2 System Programming 
Library: Data Management, OS and OS/VS Programming Support for the IBM 3505 Card Reader and 
IBM 3525 Card Punch, or IBM 3800 Printing Subsystem Programmer's Guide. 



FCB=( image- id f, ALIGN 1 



r ALIGN 1 
I, VERIFY J 




image-id 

specifies 1-4 alphameric or national characters that identify the image or module to be 

loaded into the forms control buffer. dynam 

ALIGN FCB 

requests that the operator check the alignment of the printer forms before the data set is 
printed. 
VERIFY 

requests that the operator verify that the image displayed on the printer is the desired one. 
The operator is also given an opportunity to aUgn the printer forms. 

Default: For the 3211, the image currently in the buffer. If one is not there, the operator is 
requested to specify an image. For the 3800, the machine default is 6 lines per inch for the 
form size that is on the printer. For JES2, the buffer value must have a default flag. For JES3, 
the FCB parameter defaults to a system standard or job class installation-defined default. 

General Rules for Codihg 

• The ALIGN and VERIFY subparameters are ignored for SYSOUT data sets. 

• The ALIGN subparameter is not used by the 3800. 

• Parentheses are not needed when only the image-id is specified. 

• The FCB parameter is ignored for SYSOUT data sets on the- 3525. JES2 and JES3 use it to 
request a carriage tape for a non-FCB printer or to load the FCB on a printer having the FCB 
feature. 

• STDi and STD2 should not be used as image-ids for SYSOUT unless specified by your 
installation. 

• Refer to Figure 24 for parameters that are mutually exclusive with FCB. FCB is also mutually 
exclusive with the DCB subparameters RKP, CYLOFL, INTVL, and FRID. 

Using the 3800 Printing Subsystem to Print Dumps with More Data per Page 

In order to request dump output at 8 lines per inch, specify FCB=STD3 on the dump-related 
DD statement. You can also request a dump of 204 characters per line by coding DUMP on the 
CHARS parameter of the dump-related DD statement. 
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Examples of the FCB Parameter 

//DD1 DD UNIT=321 1 ,FCB=( IMG 1 , VERIFY) 

Defines the output data set that is to be written to a 3211 printer. The FCB parameter requests 
that the data set be written using the control information corresponding to the forms control 
image with the code IMGl. Since VERIFY is coded, the forms control image is displayed on the 
printer before the data set is printed. 

//DD2 DD SYS0UT=A,FCB=IMG2 

If output class A routes output to a printer having the forms control buffer feature, JES2 loads 
the image identified by IMG2 into the forms control buffer. If the printer does not have the 
forms control buffer feature, the operator receives a message to mount the specified carriage 
tape (in this case, IMG2) on the printer. 
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//OUTPUT DD UNIT=32n ,FCB=( 6,ALIGN) ■ 

Requests that the operator check the ahgnment of the printer forms before the data set is 
printed. 

//PUNCH DD UNIT=3525,FCB=DP2 

The unit specification is for the 3525 card reader. Therefore, the FCB parameter is defining the 
data protection image to be used for the 3525. 

//SYSUDUMP DD SYSOUT=A, FCB=STD3 

Requests that the 3800 print a dump at 8 lines per inch. 
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The FLASH Parameter — keyword, optional 



The FLASH parameter identifies the forms overlay to be used on the 3800 Printing Subsystem 
and optionally, specifies the number of copies on which the forms overlay is to be printed. 

For information on designing and making or obtaining forms overlays, see the Forms Design 
Reference Guide for the IBM 3800 Printing Subsystem. 

FLASH=( overlay name [, count] ) 

overlay name 

identifies the forms overlay frame that the operator is to insert into the printer before 
printing begins (1-4 alphameric or national characters). There is no system verification that 
the operator inserted the correct frame. 
count 

indicates the number of copies (from 1 to 255) to be flashed with the overlay, beginning fcb 

with the first copy printed. flash 

Default for amnt: 255 

If is specified for count, the default is assumed. 

General Rules for Coding 

• The FLASH parameter can be specified on a SYSOUT DD statement when the 3800 is 
allocated as a system output device or on an output DD statement when the 3800 is 
allocated as a direct output device. 

• The overlay name cannot be omitted. The count subparameter is optional, but a null 
position is not allowed. (For example, FLASH=(ABCD,) is invalid.) 

• Parentheses are not needed if count is omitted. 

• FLASH can also be coded on the JES3 FORMAT PR statement or the JES2 OUTPUT statement. 

• Refer to Figure 24 for parameters that are mutually exclusive with FLASH. 

Rules for Coding Count 

• The maximum number of copies that can be flashed with the forms overlay is the value of 
nnn or the sum total of group values on the COPIES parameter. If count is greater than this 
value, the difference is ignored. 

• If count is not specified or coded as 0, aU copies printed are flashed with the specified 
overlay. 

Example of the FLASH Parameter 

//DDl DD SYSOUT=A,COPIES=10,FLASH=(ABCD,5) 

The operator receives a message to insert the forms overlay frame named ABCD into the 
printer. The first 5 copies of the data set printed are flashed with the forms overlay. 
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The FREE Parameter — keyword, optional 



The FREE parameter causes deallocation when the data set defined by a DD statement is 
closed. 

Code CLOSE whenever you don't want to monopolize resources — for example, devices, 
volumes, exclusive access rights to a data set — any longer than necessary. 

FREE= \ END ) 
\ CLOSE \ 

END 

specifies that the data set is to be deallocated at the end of the step. 

CLOSE 

specifies that the data set is to deallocated at the time it is closed. 

Default: END 

If the value is incorrectly coded, the default value is substituted and a warning message is 
issued. 

Rules for Coding 

• Code the FREE=CLOSE parameter on a SYSOUT DD statement to cause JES2 and JES3 to 
spin off the data set. 

• FREE=CLOSE should not be specified for a data set that is opened and closed more than 
once during a job step. If the data set is reopened, the job step will abnormally terminate 
unless there is an intervening dynamic allocation. 

• FREE=CLOSE is ignored for a DD statement that has a ddname of JOBCAT, JOBLIB, 
STEPCAT, or STEPLIB, or that is a member of a concatenated group. 

• Refer to Figure 24 for parameters that are mutually exclusive with FREE. 

Example of the FREE Parameter 

//EA33 DD SYSOUT=D,FREE=CLOSE 

The data set allocated to class D will be deallocated and spun off (available for printing) when 
the data set is closed rather than at the end of the job. 

//EA33 DD DSN=SYBIL,DISP=OLD,FREE=CLOSE 

The data set is dequeued when deallocated and available for someone else to use. 
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The HOLD Parameter — keyword, optional 



The HOLD parameter specifies that an output data set is to be held on a queue until released 
by a central or remote operator at the target destination, or by the time-sharing user who is 
eligible to free the data set. If you are receiving the output at the destination (work station) 
you should inform either the central operator or the work station to which the output will be 
sent to release the data set for processing. 

For further information on the HOLD parameter, see "Obtaining Output" for either JES2 or 

JES3. 



I 



HOLD= 



\ yes; 



YES 

specifies that processing of the output data set is to be deferred until the data set is 
released. 
NO 

Specifies that processing of the output data set is to proceed normally. 

Default: NO 

If an incorrect value is coded, the default is assumed and a warning message is issued. The job 
continues. 

Rule for Coding i 

The HOLD parameter can be coded only on a DD statement that includes the SYSOUT 
parameter. Otherwise, it is ignored. 

Example of the HOLD Parameter 

, • HAROLD DUQUETTE ' , MSGLEVEL^ 1 

PGM=MJCOSCO 

S YSOUT=B , DEST=RMT6 , HOLD=YES 

The output from JOBOl is held on a queue until the user identified by RMT6 or the central or 
remote operator requests that the data set be released. 



//JOBO 1 


JOB 


//STEP1 


EXEC 


//DD1 


DD 
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The LABEL PsLTwneteT—keyword, optional 



The LABEL parameter indicates the type and contents of the label or labels associated with a 
data set. 

For detailed information on tape label definitions and processing, see OS/VS Tape Labels; 
labels on direct access devices are described in OS/VS Data Management Services Guide. A 
detailed description of protecting a data set by assigning a password is included in OS/VS2 
System Programming Library: Data Management. 



LABEL=([data set sequence number] 



,SL 

.SUL 

.AL 

,AUL 

,NSL 

,NL 

,BLP 

,LTM 



iPAsswoRoiriN "I r 

,nopwread|LoutJ . 



RETPD =nnnn 
EXPDT =yyddd 



HOLD 
LABEL 



data set sequence number 

specifies the relative position of a data set on a tape volume. 
SL 

specifies that a data set has IBM standard labels. 
SUL 

specifies that a data set has both IBM standard and user labels. 
AL 

specifies that a tape data set has American National standard labels. 
AUL 

specifies that a tape data set has American National standard and user labels. 
NSL 

specifies that a tape data set has nonstandard labels. 
NL 

specifies that a tape data set has no labels. 
BLP 

Specifies that the system is to bypass label processing for a tape data set. 
LTM 

specifies that the data set can have a leading tapemark. 
I PASSWORD 

Specifies that a data set cannot be read, changed, deleted, or written to unless the operator 

or time-sharing user supplies the correct password. 
NOPWREAD 

specifies that a data set cannot be changed, deleted, or written to unless the operator or 

time-sharing user supplies the correct password. No password is necessary for reading the 
I data set. 

IN 

specifies that a BSAM data set is to be processed for input only. This subparameter overrides 
the INOUT option in the OPEN macro instruction. 
OUT 

specifies that a BSAM data set is to be processed for output only. This subparameter 
overrides the OUTIN option in the OPEN macro instruction. 
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EXPDT=yyddd 

Assign a 2-digit year number and a 3-digit day number. For example, February 2, 1973 would 

be specified as 73033. 
RETPD=nnnn 

specifies the number of days that the data set must be kept before it can be deleted or 
I written over by another data set. nnnn is a 4-digit number. 

General Rules for Coding 

• All the subparameters except the last subparameter m the LABEL parameter are positional. 
Therefore, if you code one subparameter and omit a previous subparameter, indicate its 
absence with a comma. 

• If you only want to specify the data set sequence number, RETPD, or EXPDT, you can omit 
the parentheses and code LABEL=data set sequence number, LABEL=RETPD=nnnn, or 
LABEL=EXPDT=yyddd. 

I • Refer to Figure 24 for parameters that are mutually exclusive with LABEL. 

• Do not specify both the DCB FUNC subparameter and the LABEL parameter; unpredictable 
results will occur. 

Rules for Coding Data Set Sequence Number 

• Default: If you omit this subparameter or code 0, the system assumes that this is the first 
data set on the tape volume, unless the data set is passed or cataloged. If a data set is 
cataloged, the system obtains the data set sequence number from the catalog. The data set 
sequence number for a passed data set is obtained from the passing step, 

• The data set sequence number is a 1- to 4-digit number. 



Rules for Coding Label Types 



Default: If you omit this subparameter, the system assumes that the data set has only IBM 

standard labels (SL). 

Code a comma when the label type subparameter is omitted and another positional 

subparameter follows. 

Data sets on direct access devices always have standard labels; they can optionally have 

user labels also. Therefore, only SL or SUL can be coded for data sets on direct access 

devices. SUL cannot be coded for partitioned or indexed sequential data sets. 

Label type information is not retained for cataloged or passed data sets. You must code the 

LABEL parameter and specify label type if you refer to a cataloged or passed data set that 

does not have IBM standard labels only. 

If the system does not have the bypass-label-processing (BLP) feature, specifying BLP has 

the same effect as specifying NL. 

If you specify BLP and the tape volume has labels, a tapemark delimits the data set. For a 

tape with labels to be positioned properly, the data set sequence number subparameter must 

be coded and must reflect all labels and data sets that precede the desired data set. 

If you are processing ASCII data on unlabeled tapes (NL), you must code OPTCD=Q in the 

DCB macro instruction or in the DCB parameter on the DD statement. 

Direct access devices used when referring the system to an earlier volume request, obtain 

label type information from the LABEL parameter specified in the DD statement and not 

from the source you refer it to. 
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Rules for Coding PASSWORD and NOPWREAD (no-password-read) 

• Only data sets with IBM or American National standard labels can be password-protected. 

• When adding or increasing password protection for an existing data set by coding 
PASSWORD or NOPWREAD, you must open the data set for output processing the first time 
it is used during the job step. 

• When specifying PASSWORD or NOPWREAD for a data set, a password must be assigned to 
that data set in the PASSWORD data set. If a password is not assigned, attempts to open 
that data set for output (if NOPWREAD is coded) or for input or output (if PASSWORD is 
coded) result in abnormal termination. 

• Code a comma when this subparameter is omitted and ,IN or ,OUT follows. For a new data 
set, the data set is not password-protected. 

Rule for Coding IN and OUT 

When the IN subparameter is coded, any attempt by the processing program to process the 
data set for output results in abnormal termination. If OUT is coded and the processing 
program attempts to process the data set for input, the step is abnormally terminated. 

Rules for Coding RETPD and EXPDT 

• To delete a data set before the expiration date or retention period has passed, use the 
DELETE command, as described in OS/VS Access Method Services, or the lEHPROGM 
program, as described in OS/VS2 System Programming Library: Service Aids. 

• Do not specify or imply RETPD or EXPDT for a temporary data set. 

Examples of the LABEL Parameter 

//DD1 DD DSNAME=HERBI, DISP=( NEW, KEEP ),UNIT=TAPE, 
// V0LUME=SER=T2,LABEL=( 3 ,NSL,RETPD=1 88 ) 

Defines a new data set. The LABEL parameter tells the system: (1) this data set is to be the 
third data set on the tape volume; (2) this tape volume has nonstandard labels; (3) this data 
set is to be kept for 188 days. 

//DD2 DD DSNAME=A.B.C,DISP=( ,CATLG, DELETE ),UNIT=2400=2, 

// LABEL=(,NL) 

Defines a new data set and requests that the system catalog it. The catalog entry for this data 
set will not indicate that the data set has no labels. Therefore, each time this data set is 
referred to by a DD statement, the statement must include LABEL=(,NL). 

//DD3 DD DSNAME=SPECS,UNIT=2400,VOLUME=SER=10222, 
// DI SP=OLD , LABEL=4 

Defuies an existing data set. The LABEL parameter hidicates that the data set is the fourth data 
set on the tape volume. 

PGM=FIV 

DSNAME=CLEAR, DISP=( OLD , PASS ) , UNIT=2400-4 , 

V0LUME=SER=1 257 , LABEL=( , NSL ) 

PGM=BOS 

DSNAME=*.STEP1 .DDX,DISP=OLD, LABEL=( ,NSL) 

The DD statement named DDX in STEPl defines an existing data set that has nonstandard 
labels and requests that the system pass the data set. The DD statement named ddy in STEP2 
receives the passed data set. Unit and volume information is not specified since this 
information is available to the system; the label type is not available to the system and must 
be coded. 




LABEL 



//STEPl 


EXEC 


//DDX 


DD 


// 




//STEP2 


EXEC 


//DDY 


DD 
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The MODIFY Parameter — keyword, optional | 



The MODIFY parameter specifies the name of a copy modification module to be loaded into 
the 3800 Printing Subsystem. This module contains predefined data such as legends, column 
headings, or blanks, and specifies where and on which copies the data is to be printed. The 
module is defined and stored on SYSI.IMAGELIB using the lEBlMAGE utility program. 

For further information on the copy modification module and the lEBlMAGE utility program, 
see the IBM 3800 Printing Subsystem Programmer's Guide. 

MODI FY=( module name[,trc] ) 

module name 

identifies a copy modification module previously stored in SYSI.IMAGELIB to be used to 
replace blanks or data in the printed data set. module name is 1-4 alphameric or national 
characters. 
trc 

indicates the table reference character (0-3) that corresponds to a character arrangement 
table specified with the CHARS parameter. This table is used for printing of the copy 
modification data. 



Default for trc: 

Rules for Coding 

• The MODIFY parameter can be specified on a SYSOUT DD statement when the 3800 is 
allocated as a system output device or on an output DD statement when the 3800 is 
allocated as a direct output device. 

• The trc subparameter can be coded as 0, 1, 2, or 3. The value corresponds to the sequence 
in which the character arrangement tables are specified with the CHARS parameter, (for 
example, 1 refers to the second table name coded with the CHARS parameter). 

• The module name cannot be omitted. The trc subparameter is optional, but a null position is 
not allowed. (For example, MODlFY=(A,) is invalid.) 

• Parentheses are not needed if trc is omitted. 

• MODIFY can also be coded on the JES3 FORMAT PR statement or the JES2 OUTPUT 
statement. 

• Refer to Figure 24 for parameters that are mutually exclusive with MODIFY. 

Example of the MODIFY Parameter 

//DD1 DD UNIT=3800,MODIFY=(A,0),CHARS=(GS15,GS10) 

Requests that the data in the copy modification module named A replace variable data in the 
data set to be printed by the 3800. Module A defines the positions in the data set to be 
replaced, and the copies that are to be modified. The first character arrangement table coded 
with the CHARS parameter, GS15, is used to determine the character arrangements. 
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The MSVGP Parameter — keyword, optional m 



The MSVGP parameter specifies the identification of a group of mass storage volumes that 
reside on a mass storage system (MSS) device. 

MSVGP=id 

id 

indicates a 1-8 alphameric or national character identifier (in any order) that defines the 
mass storage volume group. 

Rules for Coding 

• MSVGP is ignored for specific volume requests. The following rules apply only to nonspecific 
volume requests. 

• Refer to Figure 24 for parameters that are mutually with MSVGP. MSVGP is also mutually 
exclusive with the SPACE ABSTR and VOL=SER subparameters. 

• Positional parameters related to the VOLUME parameter can be specified with MSVGP. 

• The SPACE parameter is not required when MSVGP is used on nonspecific requests except 
for BPAM and ISAM data organization. 

• The unit count in the UNIT parameter must be less than the volume count in the VOLUME 
paramter to guarantee allocation of a non-sharable unit. 

• MSVGP results in a private volume for nonspecific volumes; therefore, coding VOL=PRlVATE 
is redundant. 

• For a new, nonspecific, permanent data set request where MSVGP is not specified, a 
mounted 3330V storage volume is used, if one exists. If one does not exist, a volume is 
selected from SYSGROUP. If a volume is selected from SYSGROUP, the SPACE parameter 
must be coded or the job is failed. 

• For a new, nonspecific, temporary data set request where MSVGP is not specified, a 
mounted 3330V public or storage volume is used, if one exists. If one does not exist or 
there is not enough space, a volume is selected from SYSGROUP. 

• To guarantee allocation to SYSGROUP for nonspecific requests, specify MSVGP=SYSGROUP. 



Example of the MSVGP Parameter 

//DD1 DD DSN=ACCOUNT,DISP=(NEW,CATLG),UNIT=3330V, 
// MSVGP=AB$ 12343, VOLUME= ( , , 3 ) 

A new, cataloged data set is to be created on one, two, or three mass storage volumes in the 
group called AB$1234@. (The installation has previously defined such a group using a mass 
storage system service and has assigned at least three volumes to this group.) Assume that this 
utility also provides a space default of SPACE=(CYL,(200,100)). 

The system will first mount any other specific mass storage volumes required for this step. 
This assumes a reference to aU old data sets in the catalog and a request for parallel mounting 
if they are multivolume. This ensures that remaining unmounted volumes in the group 
AB$1234@ do not contain other data sets required by this step. 

The system now selects an unused 3330V device to allocate to this job step. The unit will 
be marked private because MSVGP was specified. It will also be marked non-sharable because 
the volume count exceeds the unit count. The system then selects a volume from the remaining 
volumes in the group that contains at least 200 cylinders of contiguous space and causes it to 
be mounted on the allocated unit. 
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During step execution, if more than 200 cylinders are required, end of volume is entered. If 
100 more cylinders are not available on the mounted volume, it is dismounted. The system 
again selects a volume from group AB$ 1234(a) that has at least 100 contiguous cylinders and 
causes this volume to be mounted. A volume count of three will allow the data set to extend 
over up to three volumes. If more are required, the step abnormally terminates. 




MSVGP 
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The OUTLIM Paraaneter— keyword, optional ^ 

% 

The OUTLIM parameter specifies a limit for the number of logical records you want included in 
the output data set being routed through the SYSOUT data set. When the limit is reached, an 
exit may be taken to a user-supplied routine that determines whether to cancel the job or 
increase the limit. If the exit routine is not supplied, the job is terminated. For more 
information, see OS/VS System Management Facilities (SMF). 

OUTLIM=number 

number 

specifies any number between 1 and 16777215, indicating the maximum number of logical 
records to be included in the output data set being routed through the output stream. 

Default: For JES2, no output limiting; for JES3, it is an installation default. 

Rules for Coding 

• The OUTLIM parameter is ignored unless SYSOUT is coded in the operand field of the same 
DD Statement. 
j • Refer to Figure 24 for parameters that are mutually exclusive with OUTLIM. 

Example of the OUTLIM Parameter 

//OUTPUT DD SYSOUT=F,OUTLIM=1000 

The limit for the number of logical records is 1000. if 

\ 
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The QNAME F2LT2Lmeter— keyword, optional 



The QNAME parameter allows yoia access to messages received through TCAM for processing 
by an application program. 

QNAME=process name 

process name 

specifies as eight alphameric or national characters the name of a TPROCESS macro 
instruction that defines a destination queue for messages that are to be processed by an 
application program. (The first character must be alphabetic or national). 

Rules for Coding 

• The process name must be identical to the symboUc name on the TPROCESS macro. 

• The DCB parameter is the only parameter that can be coded on a DD statement with the outlim 
QNAME parameter. BLKSIZE, BUFL, LRECL, OPTCD, and RECFM are the only operands that QNAME 
can be specified as subparameters. 

Example of the QNAME Parameter 

//DYD DD QNAME=FIRST,DCB=(RECFM=F,LRECL=80,BLKSIZE=320) 

Used in an application program to define data that is used by TCAM. "FIRST" is the name of 
the TPROCESS macro that specifies the destination queue through which messages that must be 
processed by the appUcation program is to be routed. The DCB parameter suppUes information 
that was not supplied in the DCB macro instruction for the data control block. 
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The SPACE Parameter— ^^^m^on/, optional 



The SPACE parameter indicates how much space should be allocated on a direct access volume 
for a new data set. 



SPACE=AtRK ) , (primary quantity psecondary quantity"] r,directory1\ rPLSE"] rCONTIG"] [.ROUND]) 

<CYL [ |. J|_,index y \^ J ,MXIG 

( blocklengtii ) ,ALX 

'SPACE=^BSTR,{primary quantity .address f.directory"! )) 

I .index J 

TRK 

specifies that space is to be allocated by track. 
CYL 

specifies that space is to be allocated by cylinder. 
block length 

specifies the average block length of the data. The system computes how many tracks to 

allocate. 
primary quantity 

specifies how many tracks or cylinders are to be allocated, or how many blocks of data are 

to be contained in the data set. 
secondary quantity 

specifies how many more tracks or cylinders are to be allocated if additional space is 

required. This allocation can be done up to 16 times for each volume, less the number of 
. extents for primary quantity and user-label space (BDAM data sets cannot be extended.) 
directory 

specifies the number of 256-byte records that are to be contained in the directory of a 

partitioned data set. 
index 

specifies how many cylinders are required for the index of an indexed sequential data set. 

The number of tracks must equal one or more cylinders. 
RLSE 

specifies that space allocated to an output data set that is not used when the data set is 
. closed, is to be released. 

CONTIG 

specifies that space allocated to the data set must be contiguous. This subparameter applies 
only to the primary space allocation. 
MXIG 

specifies that the space allocated to the data set must be the largest area of contiguous 
space on the volume, and the space must be equal to or greater than the space requested. 
This subparameter applies only to the primary space allocation. 
ALX 

specifies that up to five different contiguous areas of space are to be allocated to the data 
set and each area must be equal to or greater than the space requested. This subparameter 

. applies only to the primary space allocation. 

■ ROUND 

specifies that space is requested by specifying the average block length of the data and that 
the space, allocated to the data set must be equal to an integral number of cylinders. 
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ABSTR 

specifies that the data set is to be placed at a specific location on the volume. 
primary quantity 

specifies the number of tracks to be allocated to the data set. 
address 

specifies the track number of the first track to be allocated. 
directory 

specifies the number of 256-b3rte records in the directory of a partitioned data set. 
index 

specifies the number of tracks that are required for the index of an indexed sequential data 

set. The number of tracks must be equal to one or more cylinders. 

General Rules for Coding 

• The SPACE parameter has no meaning for tape volumes; however, if you assign a data set to 
a device class that contains both direct access devices and tape devices, (for example, 
UNIT=SYSSQ) you should code the space parameter. 

• If you do not code secondary, directory, or index quantities, you need not enclose the 
primary quantity in parentheses. space 

• Code the second format of the SPACE parameter when you want a data set placed in a 
specific position on a direct access volume. 
Refer to Figure 24 for parameters that are mutually exclusive with SPACE. 

Rules for coding when using mass storage volumes (new data sets only) 

• The SPACE parameter must be coded when VOL=SER is coded. It is optional when MSVGP is 
coded. If you do not code VOL=SER or MSVGP, SPACE must be coded whether or not you 
code VOL=PRIVATE. 

• Contiguous space is the MSVGP default. If you want non-contiguous primary space 
allocation, you must specify the SPACE parameter. 

Rules for Coding Blocklength 

• When you request space in units of blocks, the average blocklength cannot exceed 65,535. 

• If the blocks have keys, code the DCB subparameter KEYLEN on the DD statement and 
specify the key length. 

Rules for Coding Primary Quantity 

• There must be enough available space on one volume to satisfy the primary quantity. If you 
request a particular volume and there is not enough space available on the volume to satisfy 
your request, the job step is terminated. You must consider track overflow when computing 
track requirements. 

• When specifying tracks and cylinders, the primary quantity includes the number of tracks 
and cylinders assigned to the directory. 

Rules for Coding Secondary Quantity' 

I* Code a comma when this subparameter is omitted and the directory or index subparameter 
follows. The system does not allocate additional space if it is required. 

• The system computes the number of tracks required for the secondary quantity based on 
what is specified in the DCB subparameter BLKSIZE, the DCB macro, or the SPACE 
parameter (average blocksize). 

• If you do specify a secondary quantity and the data set requires additional space, the system 
allocates this space based on the quantity you specified. The system attempts to allocate the 
secondary quantity in contiguous tracks or cylinders. If contiguous space is not available, the 



The DD Statement 237 



system attempts to allocate the secondary quantity in up to five noncontiguous blocks 

(extents) of space. i 

• Each time the data set requires more space, the system allocates the secondary quantity. 
This space is allocated on the same volume on which the primary quantity was allocated 
until: (1) there is not enough space available on the volume to allocate the secondary 
quantity, or (2) a total of 16 extents have been allocated to the data set. If either of these 
conditions is satisfied, the system must allocate the secondary quantity on another volume. 
You can specify this for a volume request by coding more than one volume in the VOLUME 
parameter. 

• If there is no more space available on those volumes that you requested, if at least one 
volume is demountable, the system will request that scratch (non-specific) volumes be 
mounted until the secondary allocation is complete. If there is no demountable volume, the 
job step will abnormally terminate. 

Rule for Coding Directory 

When creating a partitioned data set, you must request space for a directory. 

Rules for Coding RLSE 

I • Code a comma when RLSE is omitted and another subparameter follows. 

• If you specify RLSE and an abnormal termination occurs, unused space is not released. 

• The RLSE subparameter is ignored when the TYPE=T option is coded in the CLOSE macro 
instruction. 

Rules for Coding MXIG, ALX, and CONTIG 

• Code a comma when these subparameters are omitted and the ROUND subparameter 
follows. J 

• Do not code either the MXIG or ALX subparameters for an indexed sequential data set. % 

• If CONTIG is specified and contiguous space is not available, the job is terminated. 

• If you code a secondary quantity and request contiguous space, the primary request will be 
satisfied with contiguous space, but the secondary quantity will not necessarily be 
contiguous. 

Examples of ihe SPACE Parameter 

//DD1 DD DSNAME=S&TEMP,UNIT=MIXED,SPACE=(CYL, 10) 

Defines a temporary data set and requests that the system assign any available tape or direct 
access volume. (UNIT=MIXED specifies a user-assigned group name of units that consists of 
tape and direct access devices). If a tape volume is assigned, the SPACE parameter will be 
ignored; if a direct access volume is assigned, the SPACE parameter will be used to allocate 
space to the data set. The SPACE parameter includes only the required subparameters (that is, 
the t5rpe of units and a primary quantity), and requests that the system allocate 10 cylinders. 

//DD2 DD DSNAME=PDS12,DISP=( ,KEEP),UNIT=2314, 

// VOL=SER=25143,SPACE=(CYL,( 10, , 10), , CONTIG) 

Defines a new partitioned data set. The system allocates 10 cylinders to the data set and ten 
256-byte records for a directory. Since the CONTIG subparameter is coded, the system 
allocates 10 contiguous cylinders on the volume. 

//REQUEST DD DSNAME=PET, DISP=NEW, UNIT=3330 , VOL=SER=606674 , 
// SPACE=( 1 024 , ( 75 ) ) , DCB=KEYLEN=8 

The average blocklength of the data is 1024 bytes and 75 blocks of data are expected as 
output. Each block is preceded by a key eight bytes long. The system computes how many 
tracks are needed, depending on what device is requested in the UNIT parameter. 
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The SYSOUT Psarioneter-^keyword, optional 



The SYSOUT parameter assigns an output class to an output data set. 

For further information on the SYSOUT parameter, see "Obtaining Output" for either JES2 
or JES3. 

SYSOUT=( class name Lprogram namej j", f orm name"! ) 

I, J ,code name! 

class name 

specifies as an alphameric character (A-Z, 0-9) or * the class associated with the output 
device to which you want your output data set written. 

program name 

specifies the member name of an installation-written program in the system library that is to 

write the output data set, instead of JES2 or JES3. If a user-written writer is specified, it is 

executed under the control of an external writer rather than by JES2 or JES3. Notify the SYSOUT 

operator that such a data set exists so he will start an external writer. Two names, INTRDR 

and STDWTR are reserved for JES2 and JES3. (For their use and definition, see OS/VS2 

System Programming Library: Job Management.) 

form name 

is a 1-4 alphameric or national character string that specifies that the output data set should 
be printed or punched on a special output form. 

code name 

(JES2 only) is a 1-4 alphameric or national character string that points to the OUTPUT 
statement from which output characteristics will be obtained. 

Rules for Coding 

Parentheses are not needed when only the class name is specified. 

Refer to Figure 24 for parameters that are mutually exclusive with SYSOUT. SYSOUT can be 

specified with the OUTLIM, UCS, FCB, HOLD, FREE, COPIES, DSID, and DCB parameters; 

other parameters are ignored. 

To print the output data set and the messages from your job on the same output listing, 

specify the same output class in the SYSOUT parameter as you specified for messages in the 

MSGCLASS parameter. Or, specify SYSOUT=* for all data sets you want to default to the 

MSGCLASS output class. 

INTRDR causes the data set to be treated as a job stream. 
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Examples of the SYSOUT Parameter 

//DD1 DD SYSOUT=P 

Specifies that the data set is to be written to the device corresponding to class P. 



//JOB 50 


JOB 


, ' C. BROWN ' 


,MSGCLASS=C 


//STEPl 


EXEC 


PGM=SET 




//DDX 


DD 


SYSOUT=C 





The DD statement named DDX specifies that the data set is to be written to the device 
corresponding to class C. Since the classnames in the SYSOUT parameter and the MSGCLASS 
parameter on the JOB statement are the same, the system messages resulting from this job and 
the output data set can be written to the same unit record device. 

//DD5 DD SYSOUT=( F , , 2PRT ) 

Specifies that the data set is to be written to the device corresponding to class F and the 
output data set is to be printed on a special form. The form name is 2PRT. 



i 



i 
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The TERM Parameter— it^^or</, optional 



The TERM parameter notifies the operating system that a data set is coming from or going to a 
time-sharing terminal. 

TERM=TS 

TS 

indicates to the system that the input or output data being defined is coming from or going 
to a time sharing terminal. 

Rules for Coding 

• Concatenate a DD statement with a DD statement that contains TERMS=TS only if it is the 
last DD statement in a job step. 

• Code only the DCB parameter with the TERM parameter. Any other parameters coded on a sysout 
DD statement with TERM are ignored. term 

• If you code TERM on a SYSOUT DD statement and if the job is from a foreground terminal, 
the output goes to the terminal; if the job is submitted in batch, the output goes to 
whatever has been designated as the output device according to the definition given to 
SYSOUT. 

Examples of the TERM Parameter 

//DDl DD TERM=TS 

This data set (DDl) is either coming from or going to a time-sharing terminal. 

//DD3 DD UNIT=2400,DISP=(MOD,PASS),TERM=TS,LABEL=( ,NL), 
// DCB={ LRECL=80 , BLKSIZE=80 ) 

All of the parameters in this example except TERM and DCB are ignored. 
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The UCS Parsaneter-^keyword, optional 



The UCS parameter describes the character set to be used for printing an output data set on a 
1403 or 3211 printer or for SYSOUT. 

For further information on the UCS parameter, see "Obtaining Output" for either JES2 or 
JESS and OS/VS2 System Programming Library: Data Management. 



UCS=( character set coder, FOLdI [, VERIFY] ) 



character set code 

specifies 1-4 alphameric characters that identify the special character set you want for 
printing the data set. Figures 10 and 12 list the character set codes that are standard for 
JES2 and JES3. 

FOLD 

specifies that you want the chain or train corresponding to the desired character set loaded 
in the fold mode. The fold mode is described in the publication IBM 2821 Control Unit. The 
fold mode is most often requested when uppercase and lowercase data is to be printed only 
in uppercase. 

VERIFY 

specifies that the operator is to visually verify that the character set image corresponds to 
the graphics of the correct chain or train which is mounted before the data set is printed. 
The character set image is displayed on the printer before the data set is printed. 

Default: For the 3211, the image currently in the buffer. For JES2, the buffer value must have ■ 

a default flag. For JES3, by installation default or by job class. * 



Rules for Coding 



Parentheses are not needed when only the character set code is specified. 

If the chain or train mounted on the printer does not correspond to a valid character set, 

the operator is requested to identify the character set to be used, and mount the 

corresponding chain or train. 

If you code the UCS parameter and the data set is not written to a printer with the universal 

character set (UCS) feature, the UCS parameter is ignored. 

The FOLD and verify subparameters are ignored for SYSOUT data sets. 

Code a comma when FOLD is omitted and the VERIFY subparameter follows. 

For both the 3211 and 1403 printers, you can code the UCS parameter with the UNIT 

parameter. 

Refer to Figure 24 for parameters that are mutually exclusive with UCS. UCS is also 

mutually exclusive with the DCB subparameters RKP and CYLOFL. 

In order to use a particular special character set, an image of the character set must be 

contained in SYSI.IMAGELIB and the chain or train corresponding to the character set must 

be available for use. IBM provides standard special character sets and the installation may 

provide user-designed special character sets. 



c 
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Examples of the UCS Parameter 

//DD1 DD UNIT=1403,UCS=(YN, , VERIFY) 

Defines an output data set that is to be written to a 1403 printer. The UCS parameter requests 
that the data set be written using the chain or train corresponding to the special character set 
with the code YN. Since VERIFY is coded, the character set image will be displayed on the 
printer before the data set is printed, 

//DD2 DD SYSOUT=G,UCS=PN 

Defines an output data set that is to be written to the unit record device that corresponds to 
class G. If the device is a printer with the universal character set, the request in the UCS 
parameter for the special character set with the code PN will be recognized. Otherwise, the 
UCS parameter is ignored. 




UCS 
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The UNIT Parameter— *£>wor</, optional 



The UNIT parameter specifies the types and number of devices you want assigned to a data 
set. 

For further information on the use of the UNIT parameter, see "Requesting Units and 
Volumes". 



UNIT={ 
UNIT=AFF=ddname 



~jr,unit count"! 



unit address 

device type i| ,P j[, DEFER]) 

user-assigned group namej 



unit address 

specifies 3 numeric characters that identify a particular unit by its address, which consists of 

the channel, control unit, and unit numbers. 
device type (generic name) 

is an IBM-supplied name (for example, 2314) that identifies a particular device by its device 

number. A list of IBM device types is included in OS/VS2 System Programming Library: 

System Generation Reference, 
user-ass^ed group name (esoteric name) 

is a 1 to 8 alphameric character name that identifies a particular group of devices. The 

user-assigned name and the devices that make up a group are specified during system 

generation. 
unit count 

is a value from 1 to 59 that indicates the number of devices you want assigned to the data 

set. 
P 

indicates that the number of units to be allocated is equal to the number of volumes 

specified on the VOLUME parameter (the volume count subparameter or the number of 

serial numbers, whichever is higher). 
DEFER 

specifies that the system should assign a device(s) to the data set but the volume(s) on 

which the data set resides should not be mounted until the data set is opened. 
AFF 

indicates that within a job step, different data sets residing on different volumes can be 

allocated to the same unit provided that the volumes are removable (unit affinity). 
ddname 

is the name of an earUer DD statement in the job step that defines a data set with which 

you want unit affinity. 



I 



General Rules for Coding 



If you receive a passed data set or refer to a cataloged data set or earlier DD statement for 

volume and unit information (vOL=REF=reference), the system will assign one device, even 

if more devices were requested in an earlier DD statement. Therefore, you must code unit 

count for more than one device. 

Parentheses are not needed when only the first subparameter is coded. 

Code a comma when the unit count or P is omitted and the DEFER subparameter follows. 

One device is assigned to the data set. 



*! 
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• Do not identify a device by its address unless it is absolutely necessary. Specifying a unit 
address limits unit assignment and can result in a delay of the job if the unit is being used 
by another job. 

• For installations where 3340 drives with and without the fixed head feature exist, the device 
type should not be used for the unit parameter. Instead, use the unit address or a 
user-assigned group name. 

• If you code SYSOUT and unit on the same statement, the SYSOUT specification overrides 
the UNIT specification. 

• You can receive more units than you specified if you have specified volume affinity and/or 
a permanently resident or reserved volume. 

j • Refer to Figure 24 for parameters that are mutually exclusive with unit. 

Using the 3330 mod 11 

If you request a 3330 mod 11, code UNIT=3330-1. 

Using Mass Storage Volumes (MSS) 

• If you are using mass storage volumes, code UNIT=3330V. 

• To extend multivolume data sets to a non-mounted volume, the unit count must be less than 
the volume count. 

• If an old, multivolume data set resides on volumes within a group, specify paraUel mount or 
specify unit count equal to the number of volumes containing the data set. 

• Deferred mounting should not be specified for volumes belonging to a MSVGP if there are 
new data set requests in that job step using MSVGP from the same group. The delay in 
selection can result in volume confUcts within the job or between jobs causing performance 
slowdown. 

Rules for Coding User-assigned Group Names 

• A user-assigned group name can identify a device or a group of devices. The group can 
consist of devices of the same type or class, direct access and tape device classes, or 
different types of devices. 

• When you code a user-assigned group name, you allow the system to assign any available 
device from the group. If a group consists of only one device, the system will assign that 
device. 

• If a group consists of more than one device type, the units requested are allocated from the 
same device type. For example, if SYSDA contains 3330 and 2314 device types, a request 
for two units would be allocated to two 3330s or to two 2314s. 

• If a data set that was created using the user-assigned name subparameter is to be extended, 
additional units allocated to it will be of the same type as specified in the original group 
name. However, the units allocated to the data set may not necessarily be of that same 
name. 

The unit count, volume count, and volume serial number may be used to determine the 
number of units and volumes required. The greatest of the three numbers is used. 

Rules for Coding DEFER 

• If you request deferred mounting of a volume and the data set on that volume is never 
opened by the processing program, the volume is not mounted during the execution of the 
job step. 

• DEFER is ignored if a new, direct access data set is specified. 




UNIT 
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Rules for Coding AFF 



You can conserve the number of devices used in a job step by requesting that an existing 
data set be assigned the same device(s) as the data set defined on the DD statement 
specified by ddname. 

UNIT=AFF and DISP=NEW are mutually exclusive parameters if the referenced request is for 
a direct access device. If coded, the job terminates. If the referenced request is eligible for 
both tape and direct access devices, the job does not terminate; both requests are allocated 
to tape devices. 



I 



//STEP2 


EXEC 


//DDX 


DD 


// 




//DDY 


DD 


//DDZ 


DD 



Unit Override 

Volume serial information is obtained from a volume reference to a data set name, a volume 
reference to an earlier DD statement (V0L=REF), a passed data set or a cataloged data set. 
The unit description is also available from these same sources. However, you can override the 
retrieved unit information if the unit you specify is a subset of the retrieved unit. For example, 
if the retrieved unit grouping is 2314, and the specified unit description is 2314A (a subset of 
I 2314) or device address 237 (a subset of 2314), then the only units considered for allocation 
are those contained within 2314A or at the device address of 237. 

Examples of the UNIT Parameter 

PGM=POINT 

DSNAME=EST, DISP=MOD , VOLUME=SER=( 42569 , 42570 ) , 

UNIT=( 2314,2 ) 

DSNAME=ERAS , DISP=OLD , UNIT=2400-2 

DSNAME^RECK, DISP=OLD , 

VOLUME=SER=( 40653 , 1 3262 ) , UNIT=AFF=DDX 

The DD statement named DDZ requests that the system assign the same unit to this data set 
that it assigns to the data set defined on the statement named DDX. Since DDX requests two 
I devices, the same two devices are assigned to the data set defined on DDZ. 

//DD1 DD DSNAME=AAG3,DISP=( ,KEEP), 

// VOLUME=SER=13230,UNIT=2400 

Defines a new data set and requests that the system assign any 2400 9-track (that can 
read/write 800 bpi) tape drive to the data set. 

//DD2 DD DSNAME=X.Y.Z,DISP=OLD,UNIT=( ,2 ) 

Defines a cataloged data set and requests that the system assign two devices to the data set. The 
device type will be obtained from the catalog. 

//DD3 DD DSNAME=COLLECT,DISP=OLD, 

// V0LUME=SER=1 095, UNIT=( 3330, , DEFER) 

Defines an existing data set that resides on a direct access volume and requests that the system 
assign a 3330. Since DEFER is coded, the volume will not be mounted until the data set is 
opened. 

//STEPA DD DSN=FALL,DISP=OLD,UNIT=237 

The volume and unit device type are retrieved from the catalog. You can override the unit by 
specifying UNIT=237 if that unit is a subset of the device type specified in the catalog. 
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The VOLUME Farsaneter— keyword, optional 



The VOLUME parameter identifies the volume(s) on which a data set resides or will reside. 

For further information on the use of the VOLUME parameter, see "Requesting Units and 
Volumes." 



Jvolume) = 

I VOL j 



|V0LUMEW[PR|VATE] 
I VOL ^ 



.RETAIN 



n pvolu 



me sequence number 



rvolume cxiunt"! 



SER=(serial number,...) 
REF=dsname 
REF=*.ddname 
REF=*.stepname.ddname 
_REF=*.stepname.procstepname.ddname, 



PRIVATE 

specifies that: 

• no output data set is to be allocated to this volume unless the volume is specifically 

requested. 

• the volume is to be demounted after its last use in the job step, unless RETAIN is coded or 

the data set is passed. 

RETAIN 

If a private tape volume, specifies that this volume is not to be demounted after its last use 

in the job step, or at the end of the step. If a public tape volume, specifies that this volume 

is to be retained at the system if it was demounted during the job. 
volume sequence number 

specifies which volume of an existing multivolume data set you want used to begin 

processing. 
volume count 

specifies the maximum number of volumes an output data set requires. 

specifies that either the SER or REF subparameter follows and one or more subparameters 
precede it. 

SER= 

indicates that serial numbers of the volumes on which the data set resides or is to reside, are 
specified. 
(serial number,.*.) 

specifies the serial numbers of the volumes on which the data set resides or will reside. 

REF= 

indicates that the serial numbers of the volumes on which the data set resides or is to reside 

are identified on an earUer DD statement in the job or in the catalog or an earher passed 

data set. 
dsname 

specifies the name of a cataloged or passed data set. The system locates the information 

about the data set and assigns your data set to the same volumes as are assigned to the 

cataloged or passed data set. 
*.ddname 

specifies that the system must obtain the volume serial numbers from an earlier DD 

statement named "ddname" in the same job step. 
*.stepname.ddname 

specifies that the system must obtain the volume serial numbers from a DD statement named 

"ddname", which was defined in an earlier job step name "stepname." 



Q 
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*.stepnanie.procstepnaine.ddnaine 

specifies that the system must obtain the volume serial numbers from a DD statement named 
"ddname", which was defined in an earlier procedure step named "procstepname"; the 
procedure step is part of a procedure that was called by an earlier job step named 
"stepname." 

General Rule for Coding 

Refer to Figure 24 for parameters that are mutually exclusive with VOLUME. 

Rules for Coding when using Mass Storage Volumes (new data sets only) 

• VOL=SER is mutually exclusive with the MSVGP parameter. 

• The SPACE parameter is required when VOL=SER is coded. 

• To guarantee allocation to SYSGROUP for a nonspecific request, specify VOL= PRIVATE or 
MSVGP=SYSGROUP. 

Rule for Coding PRIVATE 

Parentheses are not needed when only PRIVATE is coded. 

Rules for Coding RETAIN 

• Code a comma when RETAIN is omitted and the volume sequence number or the volume 
count subparameter follows. 

• Coding RETAIN on a direct access DD statement has no effect on volume handling. 

Rules for Coding Volume Sequence Number 

• The volume sequence number must be less than or equal to the number of volumes on 
which the data set exists; it can be from 1 to 255. If a unit count greater than the 
remaining specific volumes is specified, nonspecific volumes are assigned to the remaining 
units. 

• Normally, you code a volume sequence number when you have not specified volume serial 
numbers on the DD statement (that is, you are retrieving a cataloged data set or you have 
coded a reference to an earlier DD statement or data set). If you code both a volume 
sequence number and a volume serial number in the VOLUME parameter, the system begins 
processing with the volume that corresponds to the volume sequence number. 

• The volume sequence number must correspond to a specific volume serial number or the job 
fails. 

• The volume sequence number is ignored for NEW data sets. 

• The volume sequence number overrides a DISP=M0D parameter. 

• Code a comma when the volume sequence number is omitted and the volume count 
subparameter follows. 

Rules for Coding Volume Count 

• The volume count value can range from 1 to 255. 

• If the volume count is greater than the number of specific volume serial numbers, 
non-specific volumes are added to make up the total. If the number of specific volume serial 
numbers is greater than the volume count, the volume count is ignored. 

• If the request is for a nonspecific direct access device, volume count is ignored. (The 
number of volumes equals the number of units.) 

• When you make a specific volume request and the data set might require more volumes than 
there are serial numbers, specify in the volume count subparameter the total number of 
volumes that might be used. By requesting multiple volumes in the volume count 
subparameter, you can ensure that the data set can be written on more than one volume if 

it exceeds one volume. 
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Rules for Coding SER 



• You can specify a maximum of 255 volume serial numbers for each DD statement. 

• Volume serial information is obtained from a volume reference to a data set name, a volume 
reference to an earlier DD statement (vOL=REF), a passed data set, or a cataloged data set. 

• A volume serial number must be 1 to 6 characters in length. If the number is less than 6 
characters, it will be padded with trailing blanks. It can contain any alphameric and national 
characters, and the hyphen. You must enclose any volume serial number than includes 
special characters other than the hyphen in apostrophes whenever you code that number in 
the volume parameter. 

• When using some typewriter heads or printer chains, difficulties in volume serial recognition 
may arise if you use other than alphameric characters. 

• The SER subparameter appears as the last subparameter in the VOLUME parameter. Follow 
SER= with the volume serial numbers. The serial numbers must be enclosed in parentheses 
unless there is only one serial number. If SER is the only subparameter you are coding, you 
can code VOLUME=SER=(serial number,...) or VOLUME=SER= serial number. 

• J-/0 noi 11S6 iSv.^i\. 1 C-'ri. PK.1VA 1 • or i^imnxiri i j_^ wicii iiv© iiiio!16^fics i hs s votmn© S6F1£ii nirniDGi* 
because they are used as special messages to notify the operator to mount a volume. For 
optical readers, if no volume serial number is specified, V0LUME=SER=0CRINP is assumed. VOLUME 

• Each volume must have different volume serial numbers regardless of the volume type (for 
example, tape and disk). 



Rules for Coding REF 



• To refer the system to a cataloged data set or to a data set passed earlier in the job that has 
not been assigned a temporary data set name, code REF as the last subparameter in the 
VOLUME parameter. Follow REF with the data set name of the cataloged or passed data set. 
The data set name cannot contain special characters except for periods used in a qualified 
name. References to SYSIN (DD * or DD DATA) or SYSOUT DD statements are ignored. 

• To refer the system to a data set defined earlier in the job that was not passed or was 
passed but assigned a temporary name, code REF with a backward reference to the DD 
statement that contains the volume serial numbers. 

• If the ddname refers to a DD statement that defines a dummy data set, it also is assigned a 
dummy status. 

• When referring the system to a data set that resides on more than one tape volume, the 
system begins with the last volume. When you refer the system to a data set that resides on 
more than one direct access volume, the system assigns all of the volumes. In either case, 
you can code the volume count subparameter if additional volumes may be required. 

• When coding a volume reference to a previous DD statement that uses user-assigned names, 
the system will allocate from the same device type name you made reference to rather than 
from user-assigned group names. 

• When referring to a multi-volume VSAM data set, you will receive only the first device type. 

• If the reference is to a DD statement, the label type is also copied from the referenced DD. 



Checkpoint/Restart 



• When a checkpoint data set is not cataloged, code the VOLUME parameter and specify the 
volume serial number of the volume on which the checkpoint entry is written. 

• If a checkpoint data set is cataloged, you do not need to code the VOLUME parameter 
unless the checkpoint entry exists on a tape volume other than the first volume of the data 
set; then, code either a volume sequence number or the volume serial number. If you code 
the volume serial number, you must code the UNIT parameter. 
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Examples of the VOLUME Parameter § 

//DD1 DD DSNAME=STEP,UNIT=2314,DISP=OLD, 
// VOLUME=( PRIVATE, SER=548863 ) 

Defines an existing data set and informs the system that the data set resides on the volume 
whose serial number is 548863. Since PRIVATE is coded in the VOLUME parameter, the system 
will not assign the volume to any data set for which a nonspecific volume request is made and 
will cause the volume to be demounted at the end of the job. 

//DD2 DD DSNAME=QUET, DISP=( MOD, KEEP ),UNIT=( 2400,2), 

// VOLUME=( , , ,4,SER=(96341 ,96342) ) 

Defines an existing data set that resides on the volumes whose serial numbers are 96341 and 
96342, and requests that a total of 4 volumes be used to process the data set if required. 

//DD3 DD DSNAME=QOUT,DISP=NEW,UNIT=2400 

Defines a temporary data set and, by omission of the VOLUME parameter, requests that the 
system assign a suitable volume to the data set. 



I 
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The Command Statement 



Control Statement 

The command statement specifies an operator command to be executed. 

Note: All command statements are ignored by JESS. 

For further information on commands and for descriptions of their operands, see Operator's 
Library: OS/VS2 Reference (JES2). 



r^ 



// command operand comments 



The command statement consists of the characters //in columns 1 and 2, and three 
fields— the operation (command), operand, and comments fields. 

The following JCL commands can be entered through the input stream. 



CANCEL 


MOUNT 


SETDMN 


CHNGDUMP 


PAGEADD 


START 


DISPLAY 


RELEASE 


STOP 


HOLD 


REPLY 


STOPMN 


LOG 


RESET 


UNLOAD 


MODIFY 


SEND 


VARY 


MONITOR 


SET 


WRllELOG 



Rules for Coding 






comma 



Follow the // in columns 1 and 2, with one or more blanks. 

Follow the command with one or more blanks. 

Code any required operands. Separate each operand with a coroma. 

Follow the operands with one or more blanks. 

Code any comments. 

The command statement cannot be continued. 

A command statement can appear immediately before a JOB statement, an EXEC statement, 

a null statement, or another command statement, but not before the first job in the input 

stream in JES2. 

If a command statement appears in the input stream between the boundaries of two jobs 

and it contains errors, the command will not be executed. Furthermore, you will receive no 

indication that the command was not executed. 

If you include a command statement as part of your job control statements, the command 

will usually be executed as soon as it is read. Because of this, it is not likely that the 

command will be synchronized with the execution of the job step to which it pertains. 

Therefore, you should preferably tell the operator which commands you want issued and 

when they should be issued, and let him issue them. 

Disposition is determined by JES2 according to installation options specified for each job 

class. 



Example of the Command Statement 

// DISPLAY TS,LIST 

Displays the number and user-id of all active time-sharing users of the system. 
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The Comment Statement 



Control Statement 

The comment statement specifies a comment to be included in the output Usting. 



r^ 



♦comments 



The comment statement consists of characters //* in columns 1, 2, and 3, and the 
comments field. 



Rules for Coding 

• Code the comments in columns 4 through 80. 

• You cannot continue comment statements using continuation conventions. If you cannot 
include all of the comments on one comment statement, code another comment statement. 

• The comment statement can appear an5nvhere after the JOB statement, including between 
continuations of statements. 

• With the MSGLEVEL parameter, you can request an output listing of all the control 
statements processed in your job. You will be able to identify comment statements by the 
appearance of //* in columns 1, 2, and 3. 

Example of the Comment Statement 

//*THE COMMENT STATEMENT CANNOT BE CONTINUED, 
//*BUT IF YOU HAVE A LOT TO SAY, YOU CAN FOLLOW A 
//♦COMMENT STATEMENT WITH MORE COMMENT 
//♦STATEMENTS. 




comment 
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The Delimiter Statement 



Control Statement 

The delimiter statement indicates the end of data submitted through an input stream for a step. 



comments 



The delimiter statement consists of the characters /* in columns 1 and 2 and the comments 
field. You must have at least one blank before the comments field. 

Rules for Coding 

• The system recognizes a delimiter other than /* if the DLM parameter is coded on the DD 
statement defining the data. 

• Code /* (or the value assigned in the DLM parameter) in columns 1 and 2, followed by any 
comments you have. The comments cannot be continued. 

• The beginning of data to be submitted through an input stream is indicated by a DD * or 
DD DATA statement. 

• If the data is preceded by a DD * statement and you do not code the DLM parameter, you 
need not code a delimiter statement. 

Example of the Delimiter Statement 

//JOB54 JOB , 'C BROWN' ,MSGLEVEL=( 2,0 ) 
//STEPA EXEC PGM=SERS 
//DD1 DD * 



data 



/* END OF DATA FOR THIS STEP 




delimiter 
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The NuU Statement 



Control Statement 

The null statement indicates the end of JCL statements for a job. 



r 



// 



The null statement consists only of the characters // in columns 1 and 2. The remainder of 
the statement must be blank. 



Rules for Coding 



The null statement is ignored by JES2. 

Place a null statement at the end of a job's control statements or at the end of all the 

statements in an input stream. 

If you do not follow the job's control statements and data with a null statement, the system 

places the job on the queue when it encounters another JOB statement in the input stream. 

If the job is the last job in the input stream and it is not followed by a null statement, the 

system recognizes it as the last job in the input stream and places it on the queue. 

The system flushes statements between a null statement and the next valid JOB statement. 

If a null statement follows a control statement that is being continued, the system treats the 

null statement as a blank comment field and assumes that the control statement contains no 

other operands. "" 




Example of the Null Statement 



//MYJB 


JOB 


, ' C BROWN ' 


//STEP1 


EXEC 


PROC=FIELD 


//STEP2 


EXEC 


PGM=XTRA 


//DD1 


DD 


UNIT=2400 


//DD2 


DD 


* 



data 



/* 
// 
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The PEND Statement 



Control Statement 

The PEND statement marks the end of an in-stream procedure. 



r 



//name PEND comments 



The PEND statement consists of the characters //in columns 1 and 2 and three fields — 
the name field, the operation (PEND) field, and the comments field. 

Rules for Coding 

Code // in columns 1 and 2 then code a name (1 to 8 characters) or one or more blanks. 

If you code a name, follow it with one or more blanks. 

Code PEND, and follow it with one or more blanks. 

Code any desired comments. 

Do not continue a PEND statement. The PEND statement terminates an in-stream procedure 

at that point, whether or not the statement is continued. The PEND statement must not be 

included in cataloged procedures. 

Examples of the PEND Statement 

//PR0CEND1 PEND THIS STATEMENT IS REQUIRED FOR INSTREAM PROCEDURES PEND 

This PEND statement contains a comment. 

// PEND 

A PEND statement can contain only the coded operation field preceded by // and one or more 
blanks and followed by blanks. 
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The PROC Statement 



Control Statement 



The PROC statement is the first control statement in an in-stream procedure; the PROC 
statement can also be the first control statement in a cataloged procedure. In either an 
in-stream procedure or a cataloged procedure, a PROC statement can be used to assign default 
values to symboUc parameters in the procedure. 



r 



//name PROC operands comments 



The PROC statement consists of the characters //in columns 1 and 2 and four fields — the 
name field, the operation (PROC) field, the operand field, and the comments field. 



Rules for Coding 




A PROC Statement is required for an in-stream procedure; it must appear as the first control 

statement of the in-stream procedure. 

A PROC statement is optional for a cataloged procedure; if a PROC statement is included in 

a cataloged procedure, it must appear as the first control statement. 

Code // in columns 1 and 2; then code a 1 to 8 character name or one or more blanks. A 

name is required for in-stream procedures. 

Cataloged procedures with no symbolic parameters can be created and executed. 

If you code a name, follow it with one or more blanks. Then code PROC, followed by one PROC 

or more blanks. 

In the operand field, you can assign default values to symboUc parameters in a procedure. 

Code a comma after a symboKc parameter and its default value, if you are coding more 

than one. Do not code a comma after the last symboUc parameter and its default value. 

The operand field is required in an in-stream procedure only if symbolic parameters are 

defined as in the example at the end of this section. 

Follow the operands with one or more blanks and any desired comments. 

You can continue the PROC statement onto another statement. Code // in columns 1 and 2 

of the continuation statement. 

To assign a value to a symboUc parameter, code: 

symboUc parameter=value 

Omit the ampersand that precedes the symboUc parameter in the procedure. 

The value assigned to a sjmiboUc parameter can be any length, but it cannot be continued 

onto another statement. 

If the symboUc parameter value contains special characters, enclose the value in apostrophes 

(the enclosing apostrophes wiU not be considered part of the value). 

If the special characters include apostrophes, you must code each apostrophe as two 

consecutive apostrophes. 

If you assign more than one value to a symboUc parameter with some other information, 

(for example, &JOBN0.321), the information and value cannot exceed a total of 120 

characters. 

You can override a default value appearing on a PROC statement by assigning a value to the 

same symboUc parameter on the EXEC statement that caUs the procedure. 
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//DEF 


PROC 


//NOTIFY 


EXEC 


//DD1 


DD 


// 




//DD2 


DD 


// 





Examples of the PROC Statement 

STATUS=OLD,LIBRARY=SYSLIB,NUMBER=777777 

PGM=ACCUM 

DSNAME=MGMT, DISP=( &STATUS , KEEP ) , UNIT=2400 , 

VOLUME=SER=888888 

DSNAME= SLIBRARY , DISP=( OLD , KEEP ) , UNIT=23 1 4 , 

VOLUME=SER= SNUMBER 

Three symbolic parameters are defined in this cataloged procedure: &STATUS, &LIBRARY, and 
& NUMBER. Values are assigned to the symboUc parameters on the PROC statement. These 
values will be used when the procedure is called and values have not been assigned to the 
symbohc parameters by the programmer. 

//CARDS PROC 

This PROC statement can be used to mark the beginning of an in-stream procedure named 
CARDS. 



< 
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Coding JES2 Control Statements 



The JES2 control statements are coded with JCL statements to control the input and output 
processing of jobs. Rules for coding JCL, including syntax, in the section, "Coding JCL 
Statements," apply to the JES2 control statements. However, there are additional rules for 
coding JES2 statements. They are: 

• Columns 1 and 2 always contain the characters /*. 

• JES2 statements other than the OUTPUT statement cannot be continued. You can use 
multiple control statements if more than one statement is needed. 

• Do not place JES2 control statements in a cataloged procedure; they are ignored. 

• If you code more than one statement with the same parameters, the last statement coded 
will override any other statements. 

• If you code more than one of the same parameters on the same statement, the last 
parameter coded will override any other parameters. 

• You can code the JES2 control statements in any order. However, the COMMAND and the 
PRIORITY statements must be placed in front of the JOB statement and all other JES2 
statements should follow the JOB statement. 

• The JOB P ARM statement overrides the installation default but can itself be overridden by a 
specific output statement. 



fl 
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The Command Statement 



Control Statement 



The command statement specifies JES2 operator commands that can be entered through the 
card reader or the system console. Examples in this book illustrate the format for commands 
entered through the card reader. Commands entered through the system console should omit 
the /* from the message. 

For a detailed description of the command statement and the names of the correct JES2 
verbs and operands, see Operator's Library: OS/VS2 Reference (JES2). The command statement 
consists of the characters /* in columns 1 and 2. Column 3 contains a character that is 
established at JES2 initialization by the installation or defaults to '$'. There are two fields — a 
JES2 command verb starting in column 4 followed by one or more operands. An "N" may be 
coded in column 72. Columns 73-80 are ignored. 



c 



/*$command verb operand [, operand. ..] [N] 

command verb 

an operand indicating which JES2 operator command is to be performed. 
operand 

one or more variable length operands. 

The following JES2 commands can be entered through the input stream. 

$z 



N 



$A 


$E 


$L 


$R 


SB 


$F 


$N 


$S 


$C 


$H 


$o 


$T 


$D 


$1 


$P 


$VS 



indicates that the command will not be repeated on the operator's console. 



Rules for Coding 

• Code as many command statements as are needed, but do not continue them from one 
statement to the next. 

• Command statements must be placed before jobs being entered through the input stream. 
Any command statements within a job will be ignored. 

• Commands that are entered on the command statement are executed immediately. They 
cannot be linked with any execution process of a job. 

• JES2 commands entered through the input stream are of the form /*$command. The $ is a 
JES2 initialization option. 

Example of the Command Statement 

/*$Sl3-5 

Starts initiators three through five. The command is $S and the operand is 13-5. 



{ 
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The JOBPARM Statement 



Control Statement 

The JOBPARM statement specifies job related parameters for JES2. 

The JOBPARM statement consists of the characters /* in columns 1 and 2, the word 
JOBPARM in columns 3-9, a blank in column 10, and parameters in columns 11-71. Columns 
72-80 are ignored. 

For further information, see "Obtaining Output (JES2 only)." 



[/*JOBPARM parameters 

Code one or more of the following parameters in the longer form (full word) or the shorter 
form (one letter abreviation). 



iCARDS=nnn} ( .COPIES=nnn) (.FORMS=xxxJ 

<C=nnn ) | .N=nnn \ j.F=xxx \ 

j.LINECT=nnn( 4 LINES=nnn) LNOLOGJ j.PROCLIB=xxx) 

<.K=nnn J ).L=nnn \ J.J \ j.P=xxx ( 

\yA ( ROOM = xxx) LSYSAFF=cccc) l.TIME = nnn) 

|N(f j.R=xxx \ is=cccc \ JT=nnn \ 



.RESTART= 

l.E= 




CARDS=nnn 

a value estimating the number of output cards from this job (from to 9999999 cards). 
COPIES=nnn 

a value indicating the number of printed output copies of a job related output that is to be 

produced (from 1 to 255 copies). The upper limit of this value can be reduced during JES2 

initialization. 
FORMS=xxx 

an alphameric value indicating the print and punch forms for this job's output that are not 

further defined in this job (from 1 to 4 characters). jobparm 

LINECT=nnn 

a value showing the number of lines to put on each output page for JES2 page overflow 

processing (from to 255 lines). 
LINES=nnn 

a value estimating the number of output lines from this job — in thousands of lines (from 

to 9,999). 
NOLOG 

a parameter meaning that you do not want the JES2 job log as output. (The job log contains 

a list of job related console messages and operator replies produced during processing of the 

job.) 
ROOM=xxx 

an alphameric value indicating a programmer's room number to be placed on the job's 

separators for routing SYSOUT data sets back to the programmer (from 1 to 4 characters). 
SYSAFF=cccc 

1 to 7 system affinities can be specified indicating systems to *be eligible to process this job. 

In order to specify more than one system, code: SYSAFF=(cccc,cccc,...). cccc is an 

alphameric value indicating one or more of the following: 

• * indicates the system into which the job was read. 

• ANY indicates any system in the JES2 multi-access spool configuration. 
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• cccc indicates a specific system, "cccc" must be the four alphameric character system-id 
I of one of the systems in the JES2 multi-access spool configuration. 

• ,IND when included after any of the above specifications, indicates systems scheduline in 
independent mode. 
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TIIVIE=nnn 

a value estimating the job execution time in minutes of real time (from to 279,620 
minutes). 
PROCLIB=xxx 

an alphameric value indicating the DDNAME of the cataloged procedure library that is to be 
used to convert the JCL for this job. (This name refers to a DD statement in the JES2 
cataloged procedure.) 

RESTART 

if this job is executing before a re-iPL and JES2 warm start and cannot be restarted from a 
step or checkpoint, JES2 does one of the following: 

• Y indicates that the job is queued for re-execution from the beginning of the job. 

• N indicates that no special action is taken to restart the job. N is the default. 

Rules for Coding 

• Any JOBPARM statement parameter value will supersede the equivalent parameter value 
from the accounting field (in HASP format) of the JOB statement or from any preceding 
JOBPARM statement in this job's JCL. All of these statements override the default 
established by the installation. 

• Any number of the above parameters may be placed on a single JOBPARM statement and as 
many JOBPARM statements as desired may be placed together with a given input stream. 
The JOBPARM statement cannot be continued. 

• Place the JOBPARM statement after the JOB statement. 

• If you code the PROCLIB parameter on the JOBPARM statement, the name of the DD 
statement should be in the JES2 cataloged procedure. If it is not, the JES2 default procedure 
is used. 

• If you code LlNECT=o, JES2 will not eject to a new page when the number of lines has 
exceeded the page limit that was established at JES2 initialization. 

Example of the JOBPARM Statement 

/♦JOBPARM L=60,R=4222,T=50 

The three specifications mean the following: 

L=60 The job's estimated printed output will be 60,000 lines. 

R=4222 The programmer's room is 4222. This information will be placed in the separ?itors 

for both printed and punched data sets. 
T=50 The job's estimated execution time is 50 minutes. 
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The MESSAGE Statement 



Control Statement 



The MESSAGE statement permits you to send messages to the operator (via the operator 
console) at JES2 job input time. 

The MESSAGE statement consists of the characters /* in columns 1 and 2, the word 
MESSAGE in columns 3-9, a blank in columns 10 and 11, and the message in columns 12-71. 
Columns 72-80 are ignored. 



r 



/♦MESSAGE message to be written 

Rules for Placement 

• Place the MESSAGE statement after the JOB statement. This allows the job number to be 
appended to the beginning of the message. 

• If the MESSAGE statement is not included within the boundaries of a job, the input device 
name is appended to the beginning of the message. 

Example of the MESSAGE Statement 

/♦MESSAGE CALL DEPT58 WHEN PAYROLL JOB IS FINISHED— EX. 1946 
Requests that the operator call department 58 when the payroll job is complete. 




JOBPARM 
MESSAGE 
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The OUTPUT Statement 



Control Statement 



The OUTPUT statement specifies characteristics and/or options of a specific SYSOUT data set 
or group of SYSOUT data sets. 

For further information on the OUTPUT statement, see "Obtaining Output (JES2 only)". 

The OUTPUT statement consists of the characters /* in columns 1 and 2, the word OUTPUT 
in columns 3-8, and a code beginning in column 10 followed by a blank and the keyword 
parameters. Columns 72-80 are ignored. 



r 




/♦OUTPUT code parameters 

Code one or more of the following parameters in the longer form (full word) or the shorter 
form (one letter abreviation). 

\ ,CHARS=xxxx ) ) ,COPIES=nnn J 

} ,X=xxxx ) / ,N=nnn ) 

j,COPYG=nnnf j,DEST=xxx| 

( ,G=nnn ) ] ,D=\xx ) 

J ,FLASH=overlay name/ j,FLASHC=count ) 

} ,0=overlay name ) ( ,Q=count ] 

j,INDEX=nnn} j ,LINDEX=nnn j 

( ,I=nnn ) } ,L=nnn ) 

LM0DIFY= module namef j ,MODTRC=trc ) j ,UCS=xxx ) 

|,Y=module name J^,M=trc ) ^ ,T=xxx ) 

code 

alphapieric characters referring to all SYSOUT data sets within your job whose code in the 
form number subparameter of the SYSOUT parameter matches the "code" specified on the 
OUTPUT statement (from 1 to 4 characters). Specifying code as "*" indicates that this 
OUTPUT statement is a continuation of the previous OUTPUT statement. 

BURST 

Y indicates that the printed output from a 3800 printer is to be burst into separate sheets. N 
indicates that the printed output is to be in continuous, fanfold mode. N is the default. 

CHARS=xxxx 

the name of a character arrangement table for a 3800 printer. Each name is 1 to 4 
alphameric or national characters; from one to four names can be coded. To specify more 
than one name, code: CHARS=(xxxx,xxxx...). 

COPIES=nnn 

a value indicating the number of copies of printed job-related output that is to be produced 
(from 1 to 255 copies). 

COPYG=nnn 

a value that specifies how many copies of each page of the printed output are to be grouped 
together. When COPYG is specified, it determines the number of copies to be printed (that 
is, if COPYG is coded, COPIES is ignored). The total number of copies printed equals the 
sum of the specified group values. The sum of the group values cannot be greater than 255. 
To specify more than one group value, code: COPYG=(nnn,nnn...). 

Note: This parameter applies only to the IBM 3800 Printing Subsystem (a nonimpact 
printer). If COPYG is coded and an impact printer is used, COPYG is ignored. 
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DEST=xxx 

One to four different destinations can be specified for each output data set. To specify more 
than one destination, code: DEST=(xxx,xxx...).xxx is an alphameric value indicating one of 
the following: 

• Rnnn, RMnnn, or RMTnnn - remote terminal, nnn indicating a 1- to 3-digit numeric value 
specifying the remote terminal number. 

Note: rO is equivalent to LOCAL. 

• Unnn - local terminal, nnn indicating a 1- to 3-digit decimal value specifying the local 
device with special routing. 

• LOCAL - any local device. 

• name - a 1- to 8-character (alphameric or national) name of a remote or local device (as 
defined by the system programmer). 

FCB=xxx 

an alphameric value indicating the data set forms control or carriage specifications (from 1 

to 4 characters). 
FLASH = overlay name 

the name (1 to 4 alphameric or national characters) of the forms overlay frame that the 

operator is to insert into the 3800 printer before printing begins. 
FLASHC=coiint 

a value, between and 255, that indicates the number of copies to be flashed with the 

overlay, beginning with the first copy printed. For the 3800 printer, if FLASH is specified 

and FLASHC is omitted, all copies are flashed. 
FORlVlS=xxx 

an alphameric value indicating the print and punch forms (from 1 to 4 characters). 
INDEX=nnn 

a value indicating the data set indexing print position offset (to the right) for the 3211 

printer (from 1 to 31). 




OUTPUT 
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LINDEX=nnn 

a value indicating the data set indexing print position offset (to the left) for the 3211 
printer (from 1 to 31). • 

MODIFY^module name 

the name (1 to 4 alphameric or national characters) of a copy modification module 
previously stored in SYSl.lMAGELIB that is used to replace variable data in the printed data 
set of the 3800 printer. 

MODTRC=trc 

the table reference character (0-3) that identifies a character arrangement table specified on 
the CHARS parameter. 
UCS=xxx 

an alphameric value indicating the universal character set specification (from 1 to 4 
characters). 



General Rules for Coding 



• Specifying code as "*" causes continuation of the previous OUTPUT statement, regardless of 
the position of the previous statement (that is, the previous statement does not have to 
immediately precede the continuation). The first OUTPUT statement cannot specify code as 

• Parameters specified on the OUTPUT statement will replace any equivalent parameters 
specified on the referenced DD statement. 

• Code as many OUTPUT statements as you need. If more than one OUTPUT statement has 
the same "code" starting in column 10, the first OUTPUT statement parameters are used. If 
there are duplicate parameters on the same OUTPUT statement, the last parameter overrides 
any preceding duplicate parameter. 

• Use the shorter form of the parameters when coding several parameters. 

• Place the OUTPUT statement after the JOB statement. 



Rules for Coding BEST 



If more than one destination is coded, the destinations must be in parentheses. If only one 
destination is coded, the parentheses are optional. 

Rules for Coding FCB 

• If the printer on which the data set is to be printed does not have the forms control buffer 
feature, the operator is sent a message to mount the proper carriage control tape. 

• Do not specify STDl or STD2 unless the installation indicates that you should. 

Rules for Coding INDEX and LINDEX 

If the 3211 printer has the INDEX feature, it will offset the first physical print position to the 
right by the number of print positions specified to cause the total print line width to be 
reduced by the number of print positions specified. (That is, a specification of 30 will mean 
that the maximum line width is now 30 positions less than the original value.) These 
parameters are ignored on printers other than the 3211. 

Example of the OUTPUT Statement 

/♦OUTPUT ABCD C0PIES = 6 , COPYG={ 1 , 2 , 3 ) , DEST=RMT23 

Refers to all SYSOUT data sets within the job whose DD statement specified 
SYSOUT=(c,,ABCD). Six copies of each page of output are printed. If the printer is a 3800, 
first one copy of each page is printed, then two copies of each page, and finally, three copies 
of each page. If the printer is not a 3800, COPYG is ignored and six copies of the entire data 
set are printed. 
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The PRIORITY Statement 



Control Statement 



The PRIORITY statement assigns a queue selection priority to a job. This selection priority 
applies to all of the queues to which the job or its output might be queued. A priority value 
specified on a PRIORITY statement overrides any priority specified with the PRTY parameter on 
a JOB statement. 

Note: Depending on the JES2 initialization options specified, the PRIORITY statement might be 
ignored. 

For further information on the use of PRIORITY, see "Routing a Job Through the System 
(JES2 only)". 

The PRIORITY statement consists of the characters /* in columns 1 and 2, the word 
PRIORITY in columns 3-10, and the priority code, "p", in columns 16-17. Columns 18-80 are 
ignored. 

(^/♦PRIORITY p 

P 

a number between and 15 indicating the priority of the job. 

Default: If PRIORITY is not present, or if PRIORITY is ignored, priority is derived using 
information from (1) the PRTY parameter on the JOB statement, (2) the accounting 
information on the JOBPARM statement, (3) the accounting information on the JOB statement, 
or (4) an installation-defined default. 

Rules for Coding 

• The PRIORITY statement must immediately precede the JOB statement. If it does not, or if 
"p" is not a number between and 15, the PRIORITY statement is ignored and the input 
stream is flushed until a JOB statement or another PRIORITY statement is found. 

• If "p" does not begin in column 16, the PRIORITY statement is ignored. 

Example of the PRIORITY Statement 

/♦PRIORITY 7 

The job has a queue selection priority of 7. This value only has meaning in relation to other 
jobs in the system. 
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The ROUTE Statement 



Control Statement 



The ROUTE statement specifies the destination of the output which is not specifically routed 
using the DEST parameter. 

The ROUTE statement consists of the characters /* in columns 1 and 2, PRINT or PUNCH in 
columns 10-14, and one of the device specifications in columns 16-23. Columns 24-80 are 
ignored. 

For further information, see "Obtaining Output (JES2 only)." 



/♦ROUTE ^PRINT/ / Rnnn 

/PUNCHf \ RMnn 

) RMTn 



nn \^ 
\ Unnn / 
/ LOCAL V 
' name ,/ 



PRINT 

specifies that the job's printed output is to be routed. 
PUNCH 

specifies that the job's punched output is to be routed. 
Rnnn 
RMnnn 
RMTnnn 

remote terminal, n indicating a 1- to 3-digit numeric value defining the remote terminal to 
which the output is to be sent. 

Note: rO is equivalent to LOCAL. 

Ilnnn PRIORIT' 

•Jinn r,^. .^r- 

ROUTE 

local terminal, nnn indicating a 1- to 3-digit decimal value specifying the local device with 

special routing to which the output is to be sent. 
LCXTAL 

any local device. 
name 

a 1- to 8-character (alphameric or national) name of a remote or local device (as defined by 

the system programmer) that is to receive the output. 




Rules for Coding 



• A ROUTE statement can be used to direct either print or punch routing of output, but not 
both. If both print and punch are to be routed, two cards must be used. 

• Place the ROUTE statement after the JOB statement. 
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Examples of the ROUTE Statemeni 

/♦ROUTE PRINT RMT6 

Routes printed output to remote terminal 6. 



/♦ROUTE PUNCH PUNCH2 

Routes punched output to device "PUNCH2" as defined by the system programmer. 
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The SETUP Statement 



Control Statement 



SETUP is a control statement which is used to indicate volumes needed for executing a phase 
of the job. 

For further information on the use of the SETUP statement, see "Routing a Job Through the 
System (JES2 only)". 

The SETUP statement consists of the characters /* in columns 1 and 2, the word setup in 
columns 3-7, and volume serial numbers that begin in column 16. Columns 72-80 are ignored. 



G 



SETUP volume serial number [, volume serial number...] 



volume serai niunber 

identifies the volume or volumes required for execution of the job. 

Rules for Coding 

• All SETUP Statements should be placed after the JOB statement. 

• As many SETUP statements as rwcessary can be used. 

Example of the SETUP Statement 

/♦SETUP 66632 1 , 1 49658 

The two volumes requested are listed on the console when the job enters the system. The job 
is then placed in the hold status awaiting release by the operator when the required volumes 
are available. Tlie message infQirns the operator that the volumes should be mounted before 
the job is run. 




ROUTE 
SETUP 
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The SIGNOFF Statement 



Control Statement 



SIGNOFF is a control statement that indicates to the central computer that the user wishes to 
terminate a remote job stream processing session. At the completion of the current print 
and/or punch streams, JES2 disconnects the station from the system. If jobs are being read into 
the system from the remote station when the output. is completed, JES2 disconnects the remote 
station when the input is completed. 

Both SNA (systems network architecture) and BSC (binary synchronous communication) 
remote work stations can use the SIGNOFF statement. SN.A remote stations, however, can also 
use the LOGOFF command to end a session with JES2. The LOGOFF command has some 
options that are not provided by the SIGNOFF statement. For a discussion of the LOGOFF 
command, refer to OS/VS2 MVS System Programming Library: JES2 and OS/VS2 MVS System 
Programming Library: VTAM. 

The SIGNOFF statement consists of the characters /* in columns 1 and 2, and the word 
SIGNOFF in columns 3-9. 



(. 



/*SIGNOFF 

Example of the SIGNOFF Statement 

/*SIGNOFF 

Requests that a remote job stream processing session be terminated. 
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The SIGNON Statement 



Control Statement 



SIGNON is a control statement that indicates to the central computer that the user wishes to 
begin a remote job stream processing session. The SIGNON statement overrides the remote 
identification number normally assigned to the remote station. This statement is optional for all 
work stations except non-multi-leaving remote stations on a switched line. 

Note: SNA remote work stations must use the LOGON command instead of the SIGNON 
statement to notify JES2 of a connection request. For a discussion of the LOGON command, 
refer to OS/VS2 MVS System Programming Library: JES2 and OS/VS2 MVS System Programming 
Library: VTAM. 

The SIGNON statement consists of the characters /* in columns 1 and 2, the word SIGNON 
in columns 3-8, and REMOTEnnn starting in column 16. The i^lGNON statement can also 
include two passwords: one beginning in column 25 and the other in column 73. 



C 




/*SIGNON REMOTEnnn [password 1 ] [password2] 

mm 

a value specifying the remote identification number assigned to the remote station that is 

requesting to sign on. 
password 1 

a password, assigned to a dial line, that allows the remote station access to JES2 for remote 

job stream processing. This password is established at JES2 initialization, and can be 

changed or deleted by the operator with the $T command. 
password2 

a password that ensures that the remote station signing on is a valid RJE (remote job entry) 

station. This password is established at JES2 initialization. 

SIGNOFF 

Rules for Coding signon 

• For multi-leaving remote stations, the SIGNON statement is put at the end of the JES2/RTP 
program deck. 

• For non-multi-leaving remote stations, the SIGNON statement is transmitted alone as part of 
the initial connection process. 

Example of the SIGNON Statement 

/*SIGNON REMOTE123PSWD 

Requests that remote station 123 begin a remote job stream processing session. PSWD, 
beginning in column 25, is the password assigned to a dial line. 
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Coding JES3 Control Statements 



The JES3 statements are coded with JCL statements to control the input and output processing 
of jobs. Rules for coding JCL, including syntax, in the section "Coding JCL Statements," apply 
to the JESS statements. However, there are additional rules for coding JES3 statements. They 
are: 

• Columns 1 through 3 always contain the characters //*. (Column 4 must be a non-blank). 
For compatibility, ASP version 2 control statements supported by JESS can be coded with a 
/* in columns 1 and 2. (Note: SETUP statements from ASP version 2 will be ignored.) 

• JESS statements can be continued by punching a comma as the last character of the first 
card, punching //* in columns 1 through 3 of the continuation card, and resuming the text 
in column 4 of the continuation card. 

• JESS control statements, except the command statement, must appear after the JOB 
statement, including all JOB continuation cards. JESS statements that appear before or in the 
middle of the JOB statement are ignored. 

• Do not place JESS control statements in a cataloged procedure; they are ignored. 

• Do not include comments on JESS control cards. 



^^^ 
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The Command Statement 



Control Statement 



i 



The command statement specifies JES3 operator commands, except *DUMP and *RETURN, that 
are entered only through the card reader or the system console. Examples in this book 
illustrate the format for commands entered through the card reader. Commands entered 
through the system console should omit the //* from the command. 

For a detailed description of the command statement and the names of the JES3 verbs and 
operands, see Operator's Library: OS/VS2 Reference (JES3). There are two fields — a JES3 
command starting with an asterisk in column 4 followed by one or more operands. Columns 
73-80 are ignored. 



f 



//** command- verb [operand , operand, 



♦command-verb 

indicates which JESS command the operator is to perform. 



CALL 


X 


INQUIRY 


I 


CANCEL 


c 


MESSAGE 


Z 


DELAY 


D 


MODIFY 


F 


DISABLE 


H 


RESTART 


R 


ENABLE 


N 


SEND 


T 


ERASE 


E 


START 


S 


FAIL 




SWITCH 




FREE 




VARY 


V 



operand ^ 

one or more operands pertaining to the command-verb. 



Rules for Coding 



I • Begin the command- verb in column 5; code it in the same format as if it were being entered 
from a console. 

• All command statements must precede the first JOB statement in the input stream if jobs are 
also being submitted. If any command statements follow the JOB statement, they are 
considered comments statements. 

• Multiple command statements can be entered at one time. 

• These statements can be placed as the first cards in an active card reader that is being 
restarted. 

• Command statements cannot be continued from one statement to another. 

• Commands that are entered on the command statement are executed immediately. They 
cannot be linked with any execution process of a job. 



c 
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Examples of the Command Statement 

//**VARY , 280 , OFFLINE 
//**V,281 , OFFLINE 
//**VARY,282,OFF 

-or- 
//**V, 280-282, OFF 

Several devices are varied offline by coding either three separate commands or one command 
for all devices to be varied offline. If these cards are placed in card reader OIC, for example, 
and it is currently not in use, the operator would then enter: 

*X CR,IN=01C 

//**MESSAGE,CN1 , OUTPUT FROM JOB X REQUIRES SPECIAL CONTROLS 

Gives a special instruction to the operation staff from a remote location. This card is placed in 
front of the first job. 




commarv 
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The DATASET Statement 



I 



Control Statement 



The DATASET statement defines the beginning of an additional input stream data set that can 
contain JCL and/or data. The data set can be used as input to a DSP (for example, OUTSERV), 
or a job executing on an ASP main processor. Terminate a data set by coding an ENDDATASET 
statement. 



(' 



//♦DATASET DDNAME=ddname [ , MODE= 



e)] [,j=/no )] 

Cj |YESj 



Defaults: MODE=E 
J=NO 



DDNAME 

defines the ddname used to reference the spooled data set. 
MODE 

defines the card reading mode. 

• E specifies that the cards are read as EBCDIC with validity checking. 

• C specifies that the cards are read in card image form (column binary or data mode 2). 



determines how the data set is terminated. 

• NO indicates that a JOB statement will terminate the data set. 

• YES indicates that JOB statements can be included in the data set and an ENDDATASET 
statement will terminate the data set. 



I 



General Rules for Coding 



• MODE=C is invalid for jobs read from disk or tape, and for jobs submitted from remote 
work stations. 

• When a data set specified in a DATASET statement is to be used as input to a job executing 
on an ASP main processor, the DD statement referencing that data set must include the 
following parameters: 

//ddname DD UNIT=( CTC , , DEFER ) , 

// VOL=SER=dummy-name, 

// DCB=( RECFM=F , LRECL=80 , BLKSIZE=80 ) 

ddname 

as specified in the DDNAME parameter of the DATASET statement. 
dununy-name 

a dummy serial number. A unique name must be chosen for each data set in the job and 
must not dupUcate the name of a real volume (tape or disk). 

Note: CTC is defined, by the installation as a generic name at SYSGEN. 
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Rules for Coding when MODE = C 



• The J parameter is ignored when MODE=C is specified. The data set must be terminated 
with an enddataset statement. 

• You must ensure that the operator includes the C operand on the *CALL operator command 
for the reader that reads this job. 

• In the DD statement referencing the data set for input to an ASP main processor, 
LRECL=160 and blksize=160. 



Examples of the DATASET Statement 

//♦DATASET DDNAME=MYPRINT 

data cards 
//♦ENDDATASET 
//♦PROCESS OUTSERV 
//♦FORMAT PR , DDNAME=MYPRINT , C0PIES=5 



Creates a data set, ddname=MYPRINT, and prints five copies. 



//DD5 DD 


SYSOUT=A 


//DD6 DD 


UNIT=( CTC, , DEFER ) , VOL=SER=DUMMY, 


// 


DCB=( RECFM=F,LRECL=80,BLKSIZE=80 ) 


//♦DATASET 


DDNAME=DD6 




data cards 


//START JOB 


MSGLEVEL=( 1,1) 


//STEP EXEC 





Creates a data set that can be referenced by ddname dd6. The data set contains the 
information between the //*DATASET statement and the JOB statement. 




DATASET 
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The ENDDATASET Statement 



Control Statement 

I The ENDDATASET Statement terminates the creation of a JES3 input stream data set that was 
defined by the DATASET statement. 

^//♦ENDDATASET 

Rule for Coding 

The ENDDATASET Statement must appear immediately after the last card for that data set. 

Example of the ENDDATASET Statement 

//♦DATASET DDNAME=MYPRINT 

data cards 
//♦ENDDATASET 
//♦PROCESS OUTSERV 
//♦FORMAT PR , DDNAME=MYPRINT , C0PIES=5 

Creates a data set, ddname=MYPRINT, and prints five copies. 



I 
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The ENDPROCESS Statement 



Control Statement 

The ENDPROCESS Statement indicates the end of a series of PROCESS statements for the job 
JCL in which it appears. No more PROCESS statements can be included in this job. The use of 
the ENDPROCESS Statement is optional if any JCL statement follows the last PROCESS 
statement; otherwise, the ENDPROCESS statement must be used after the last PROCESS 
statement. 



C 



//♦ENDPROCESS 

The ENDPROCESS statement has no operands. 
Example of the ENDPROCESS Statement 

//♦ENDPROCESS END OF PROCESS STATEMENTS 




ENDATASET 
ENDPROCESS 
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The FORMAT Statement 



Control Statement 



I 



The FORMAT statement communicates special destination and format related instructions to the 
system for processing the print and punch data sets. 

y NJP( 

//♦FORMAT ) PR ( 

V PU / 

AC 

indicates data sets that are destined for TSO terminal users connected on ASP main 

processors. 
NJP 

indicates this card is associated with network job processing. 
PR 

indicates this card is associated with a print data set. 
PU 

indicates this card is associated with a punch data set. 



General Rules for Coding 



There must be at least one blank between FORMAT and PR, PU, and AC. 

The text depends on the type of data set and is explained on the following pages. ^i 

Multiple FORMAT statements can be used for any data set to specify special requirements I 

for each copy of the data set. 

Classes are established at initialization that group characteristics for job output. See the 

system programmer to determine if you should use one of the defaults or should code the 

FORMAT statement. 

FORMAT statements are required for special data set processing such as multiple 

destinations, multiple copies of output having different attributes, forced single or double 

space control, and printer overflow checking. For information on special (nonstandard) jobs, 

see the section, "The PROCESS Statement". 



I 
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The AC Parameter 



JES3 created data sets are routed to TSO users running on ASP main processors. ASP main 
processor TSO users should use ASP TSO output classes defined by the installation as being held 
to retrieve their output. This reduces the need for FORMAT AC control statements. (Jobs of 
TSO users running on ASP main processors are physically connected to an ASP system 
regardless of where the job is run.) For further information, see "Obtaining Output (JES3 
only)." 



//♦FORMAT 



AC , DDNAME= ( ddname ^ 
) SYSMSG ( 



[,DEST= 



) JESJCL ( 

{ JESMSG ; 
ANYLOCAL 
device-name 
device-address 
group-name 
LOCAL 



type 



[ ,USER=userid] 
[,PRINT= ^ YES M 

[no i 

[ , hold= \ yes i ] 
Ino ( 
[ ,MAIN=main-name] 



, device-name 
, device-address 
, group-name 
, LOCAL 



Defaults: PRINT=NO 
HOLD=NO 

DDNAME 

• ddname specifies the ddname of the DD statement that defines the data set that the user 
desires to access. This ddname should be qualified to the same level 
(stepname.procstepname.ddname), and match exactly, the ddname on the associated DD 
statement. 

• SYSMSG specifies system messages, 

• JESJCL specifies jclfile including statement messages. 

• JESMSG specifies JES3 and system operator messages (job log). 

DEST 

specifies the device name of a printer or punch used to print or punch the output in the 
event this output is not sent to the user. 

• ANYLOCAL specifies that any device (either a printer or punch as defined by the output 
class on the DD statement) attached to the central CPU may receive the output data set. 

• device-name specifies the 1-8 alphameric or national character name of a local printer or 
punch (as defined by the system programming staff) to receive the output data set. 

• device-address specifies the three character physical device address of the device to 
receive the output data set. 

• t5rpe is in the format gggssss where ggg is the general device classification (for example, 
PRT) and ssss is the specific device classification (for example, 3211) as defined by the 
system programming staff. t3rpe must be enclosed in parentheses. 




FORMAT 
AC 
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• group-name specifies the name of a group of local devices, an individual remote station, 
or a group of remote stations to receive the output data set. 

• LOCAL specifies the default group-name for local devices (that is, those local devices that 
are in no other group). There must be at least one local device that is not assigned to a 
group in order for the data set to be printed. 

USER 

identifies this data set with the specified TSO user even though the job was not submitted 
from TSO by that user. This parameter allows: 

• this SYSOUT data set to be sent to an ASP main processor (see main) for use by the TSO 
user. 

• the TSO user on an MVS processor (global or local) to access this SYSOUT data set with 
the TSO OUTPUT command. 

• the TSO user on any processor to inquire about the status of this data set. 

PRINT 

specifies whether or not the output is to be printed. 

• YES specifies that the data set is printed. 

• NO specifies that the data set is not printed. 
HOLD 

Specifies the disposition of this SYSOUT data set which has been routed to a TSO user on an 
ASP main processor. 

• YES prevents the data set from being printed or punched untU the associated TSO user 
(MVT or VS2-1 only) issues a RELEASE command for the job. 

• NO allows the data set to be printed or punched immediately after being sent to the main 
processor. 

MAIN 

identifies this data set with the specified processor even though the job was not submitted 
from or executed on that processor. This parameter allows: 

• this SYSOUT data set to be sent to the asp main processor (see USER). 

• the job termination message IAT6108 to be sent to the processor if the NOTIFY 
parameter was coded on the JOB card. 



Rules for Coding DDNAME 



• The ddname should be qualified to the level required. 

• The referenced dd statement must be in the form: 

//name DD SYSOUT=class 



Rule for Coding DEST 



The name specified must be a valid JES3 device name, group name, or remote destination; that 
is, one defined by the installation. 



Rule for Coding MAIN 



The MAIN parameter specifies on what processor the TSO user will be connected for receiving 
output when the input comes from another destination. This parameter is not required when 
submitting and receiving from the same TSO destination. 



< 



< 
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Example of the AC Parameter 

//♦FORMAT AC , DDNAME=SYSMSG , DEST=PR2 , USER=TSOA , PRINT=YES 

The data set SYSMSG is printed on PR2 and TSO user tsoa is notified. 




FORMAT 
AC 
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The NJP Parameter 4 

\ 

The network job processing (NJP) parameter defines the remote station from which and to 
which the job will be transmitted. 

//♦FORMAT NJP , FROM=SYStem-name , DEST=SYstem-name 

FROM 

specifies the name of the JES3 system from which the job will be transmitted. 
DEST 

specifies the name of the JES3 system to which the job will be transmitted. 

Rules for Coding 

j • The system-name is determined at initialization time. For information on these statements, 
see the system programming staff. 
• The ke5rwords, FROM and DEST can be coded in any order. 

Example of the NJP Parameter 

//♦FORMAT NJP,FROM=NYC,DEST=LA 

The job is transmitted from NYC to LA for processing. 



{ 
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The Print Parameter 



The PR parameter specifies print characteristics of a JES3 output data set. 
For further information, see "Obtaining Output (JES3) only)." 



//*FORMAT 



PR,DDNAME= Tddname 
SYSMSG 
JESJCL 

ljesmsgj 
, destYanylocal 

Idevice-name 
Idevice-address 
[group-name 
<; LOCAL 
I (type p, device-name 

, device-address 
, group-name 
, LOCAL 

,CONTROL= /PROGRAMS ] 
j SINGLE f 
) DOUBLE ( 

(triple ; 

( nnn [ , ( group value , group value ... ) ] ) ] 
j STANDARD \ ] 
^form-name ) 
jGLPI 

Hmage-name 
,CARRIAGE=i6LPI ( 

< carriage-tape-name ) 

(standard 

/(table name [, table name. 
? STANDARD 

ic 

J STANDARD f 

/(overlay name [, count] ) ) 
(module name[,trc] )] 



[,COPIES= 
[ , FORMS = 

[,FCB= 



■CHARS= 



[STACKER= 



■FLASH= 



[MODIFY^ 
[,OVFL=^ON ( 
/OFF J 
[ , PRTY= nnn ] 



Defaults: CONTROL=PROGRAM 

C0PIES=1 

FORMS=STANDARD 

FCB=6LPI 

CARRIAGE=6LPI 

OVFL=ON 
DDNAME 

• ddname specifies the ddname of the data set to which this statement applies. This 
ddname should be qualified to the same level (stepname.procstepname. ddname), and 
match exactly, the ddname on the associated DD statement. 

• SYSMSG specifies system messages. 

• JESJCL specifies jclfile including statement messages. 

• JESMSG specifies JES3 and system operator messages (job log). 
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DEST § 

specifies the printer used for output. * 

• ANYLOCAL specifies that any device (a printer as defined by the output class on the DD 
statement) attached to the central CPU may receive the output data set. 

• device-name specifies the 1-8 alphameric or national character name of a local printer (as 
defined by the system programming staff) to receive the output data set. 
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• device-address specifies the three character physical device address of the device to m 
receive the output data set. 

• type is in the format gggssss where ggg is the general device classification (for example, 
PRT) and ssss is the specific device classification (for example, 3211) as defined by the 
system programming staff, type must be enclosed in parentheses. 

• group-name specifies the name of a group of local devices, an individual remote station, 
or a group of remote stations to receive the output data set. 

• LOCAL specifies the default group-name for local devices (that is, those devices that are 
in no other group). There must be at least one local device that is not assigned to a 
group in order for the data set to be printed. 

CONTROL 

Specifies the type of forms control used. 

• PROGRAM indicates that the carriage control character is the first character of each 
logical record in the data set. 

• SINGLE indicates forced single spacing. 

• DOUBLE indicates forced double spacing. 

• TRIPLE indicates forced triple spacing. 

COPIES 

Specifies the number of original copies to be printed for this data set. 

• nnn can range from to 255. 

• group value describes the grouping of the printed copies (for the 3800 only). Each group 
value can range from 1 to 255. 

FORMS A 

specifies the printer forms used. % 

• STANDARD indicates that standard installation forms are used. 

• form-name can be from 1 to 8 characters and indicates the form name or form number 
of special forms to be mounted. 

FCB 

specifies the name of the forms control buffer used (for the 3211 or 3800). 

• 6LPI specifies that the installation standard forms control buffer is used. 

• image-name is a 1- to 4-character string consisting of the last characters of the FCB2xxxx 
member (for a 3211) or FCB3xxxx member (for a 3800) located in SYSI.IMAGELIB. 

CARRIAGE 

specifies the carriage tape for either 3211 or 1403 to print onto this SYSOUT class. 

• 6LPI specifies that the installation standard carriage tape is used. 

• carriage-tape-name can be from 1 to 8 characters. 

CHARS 

specifies the names of character arrangement tables for printing a data set w^ith the 3800. 

• STANDARD indicates that the standard installation character arrangement table is used. 

• table name is 1 to 4 alphameric or national characters identifying the name of the table. 

STACKER 

specifies which stacker of the 3800 Printing Subsystem the paper output is to go to. 

• STANDARD indicates that the standard installation default is used. 

• s indicates that the Burster-Trimmer- Stacker is used. 

• C indicates that the continuous forms stacker is used. 

FLASH J 

identifies the forms overlay to be used on the 3800. I 
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• STANDARD indicates that the standard installation forms overlay is used on all copies 
printed. 

• overlay name is 1 to 4 alphameric or national characters identifying the forms overlay 
frame to be used. 

• count indicates the number of copies (from 1 to 255) to be flashed with the overlay. 

See the Forms Design Reference Guide for the IBM 3800 Printing Subsystem for information on 
designing and making forms overlays. 

MODIFY 

specifies the name of a copy modification module used to replace blanks or data in the data 
set printed by the 3800. See the IBM 3800 Printing Subsystem Programmer's Guide for more 
information. 

• module name is 1 to 4 alphameric or national characters identifying the module 
previously stored in SYSI.IMAGELIB. 

• trc is a table reference character from to 3 that corresponds to a character arrangement 
table specified with the CHARS parameter. 

OVFL 

specifies whether or not the printer program should test for forms overflow. 

• ON specifies that the printer program should eject whenever the end-of -forms indicator 
(channel 12) is sensed. 

• OFF specifies that forms overflow control is not used. 

PRTY 

specifies the priority at which the data set is to enter the output queue, nnn can range from 
to 255. 




FORMAT 
PR 
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Rules for Coding DDNAME 



The ddname should be qualified to the level required. 

When DDNAME=, is coded, the parameters specified on this statement become the defaults 

for the job and apply to all print data sets that have no FORMAT statements. 



Rules for Coding BEST 



• If the parameter is omitted, the first available printer in the origin group (the group of 
printers defined for the local or remote submitting locations) that fulfill all processing 
requirements is assigned. If the job originated at a remote RJP terminal, the output is 
returned to the originating terminal group. 

• The PR DEST parameter overrides the MAIN ORG parameter. 



Rule for Coding CONTROL 



When coding CONTROL=PROGRAM, the character specified can be either the extended 
US ASCII code or the actual channel command code for the System/ 3 60 and System/ 3 70 
channel. 



Rules for Coding COPIES 



• Parentheses are not needed when only nnn is coded. 

• If zero is specified, printing for this data set is bypassed. 

• The group value subparameter is for the 3800 only. When group values are coded, they 
override nnn. 

• A maximum of 8 group values can be coded. Their sum total must not exceed 255. 



Rules for Coding FCB 



• FCB and CARRIAGE are mutually exclusive on the FORMAT statement. 

• FCB should only be used when requesting a 3211 or 3800 printer; otherwise it is ignored. 

Rules for Coding CARRIAGE 

• CARRIAGE and FCB are mutually exclusive on the FORMAT statement. 

• For 3211 printers, a module must be included in SYSI.IMAGELIB for each carriage tape 
name. 

Rules for Coding CHARS 

• From 1 to 4 table names can be specified. Parentheses are not needed when one table name 
is coded. 

• Figure 28 A gives the names of character arrangement tables supplied for the 3800. 



^^ 



FORMA' 
PR 



Rules for Coding FLASH 



• Parentheses are not needed if count is omitted. 

• If count is not specified or coded as 0, all copies printed are flashed with the specified 
overlay. 



Rules for Coding MODIFY 



Parentheses are not needed if trc is omitted. 

If trc is not specified, the first character arrangement table coded with the CHARS parameter 

is used for printing the data. 

The copy modification module is defined and stored using the lEBlMAGE utility program. 
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Rule for Coding OVFL 

For remote job processing, the overflow test is a responsibility of the terminal package for the 
remote RJP terminal. OVFL is ignored for remote job processing. 

Examples of the Print Parameter 

//♦FORMAT PR,DDNAME=REP0RT,C0PIES=2 

Specifies that two original copies of the data set defined by REPORT are requested. Any printer 
with standard forms, train, and carriage tape mounted can be used. 

//*FORMAT PR , DDNAME= , DEST=ANYLOCAL 

Specifies that all data sets without FORMAT statements are printed on any local printer. 



i 



i 
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The Punch Parameter 



The PU parameter specifies punch characteristics of a JES3 output data set. 
For further information, see "Obtaining Output (JES3 only)." 



//♦FORMAT PU , DDNAME=ddname 
[ , DEST=/ ANYLOCAL 

device-name 
device-address 
Igroup-name 
LOCAL 



'( type 



, device-name 
, device-address 
, group-name 
L , LOCAL 



[,COPIES= nnn ] 

[ , FORMS= j STANDARD 

] form-name 
[,INT= JYESn 

Ino ( 



Defaults: C0PIES=1 

FORMS=STANDARD 

INT=NO 
DDNAME 

specifies the ddname of the data set to which this statement applies. This ddname should be 
qualified to the same level (stepname.procstepname. ddname), and match exactly, the 
ddname on the associated DD statement. 
DEST 

specifies the punch unit used for output. 

• ANYLOCAL specifies that any device (a punch as defined by the output class on the DD 
statement) attached to the central CPU may receive the output data set. 

• device-name specifies the 1-8 alphameric or national character name of a local punch (as 
defined by the system programming staff) to receive the output data set. 

• device-address specifies the three character physical device address of the device to 
receive the output dat^ set. 

• type is in the format gggssss where ggg is the general device classification (for example, 
PUN) and ssss is the specific device classification (for example, 3525) as defined by the 
system programming staff, type must be enclosed in parentheses. 

• group-name specifies the name of a group of local devices, an individual remote station, 
or a group of remote stations to receive the output data set. 

• LOCAL specifies the default group-name for local devices (that is, those local devices that 
are in no other group). There must be at least one local device that is not assigned to a 
group in order for the data set to be printed. 

COPIES 

Specifies the number of copies of the data set that are to be punched, nnn can range from 
to 255. 
FORMS 

Specifies the card forms used. 

• STANDARD specifies that installation forms defaults are used. 

• form-name can be from 1 to 8 characters and indicates the card forms to be used. 



i 
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INT 

specifies whether or not the output is interpreted. 

• YES causes an attempt to obtain a device type PUN3525I (a card punch with the interpret 
feature). If DEST does not include a 35251, INT=N0 is substituted. 

• NO causes no interpreting of these cards. 



Rules for Coding DDNAME 



• The ddname should be qualified to the level required. 

• When DDNAME=, is coded, the parameters specified on this statement apply to all punch 
data sets that have no FORMAT statements. 

Rules for Coding DEST 

• If the parameter is omitted, the first available punch unit in the job origin group (the group 
I of punches defined for the local or remote submitting locations)y^that fulfills all processing 

requirements is assigned. If the job originated from a remote RJP terminal, the output is 
returned to the originating terminal group. 

• The PU DEST parameter overrides the MAIN ORG parameter. 

Rule for Coding COPIES 

I 

If zero is specified, punching for this data set is bypassed. 

I 
Example of the Punch Parameter 

//♦FORMAT PU , DDNAME=PUNCHOUT , DEST=PU 1 , FORMS =RED-STRP 

I One copy of the data set defined by punchout is punched on unit PUl. Before processing, 
the operator is requested to insert "RED-STRP" cards into the designated punch. 




FORMAT 
PU 
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The MAIN Statement 



i 



Control Statement 



The MAIN statement defines the processor requirements for the current job. Many of the 
parameters are used to override parameters of the STANDARDS initialization control card. 



//*MAIN ISYSTEM= 



ANY 

JGLOBAL 

J LOCAL 

ASP 

main -name 

(main-name, main-name, . 

/main-name 

/(main -name, main - name. 



[,LINES=([nnn] 



t,CARDS=([nnn] 



,WARNING 
,W 

,CANCEL 
,C 

,DUMP 
,D 

•.WARNING" 
,W 

,CANCEL 
,C 

,DUMP 
,D 



)] 



[,HOLD= ^NO h 
(YES/ 

[,SETUP= /job 
HWS 
THWS 
DHWS 
ddname 

(ddnanne,ddname, . 
/ddname 
/(ddname, ddname, , 

[ ,C L ASS=class - na me ] 

I,FAILURE= /RESTART \ ] 
j CANCEL f 
J HOLD ( 

'print ; 

[,EXPDTCHK=|;;^^|] 



[,JOURNAL= 



ftol 



[,JOBSTEP= (nOCHKPNt) ] 
|CHKPNT f 

[,TYPE= /ANY \ ] 
IMVT I 
WS2/1 { 

'vs2 ; 

[,NJPCLASS=class-name] 
[,H0TJ0B= (no ) ] 



/no ) ] 
\yes/ 



[,IORATE= (MED 
<HIGH 

(lo 

[,ORG=group-name] 
[,DEADLINE= 



(time,type, [, (date ) 
|^rel,cyclej 



])] 



t,FETCH= /ALL 
NONE 
SETUP 
ddname 

(ddname, ddname, . . . ) 
/ddname 
/(ddname, ddname, . . . ) 

[,JPRTY= (JES3)] 
■|jOB j 

[,LREGION=nnnnK] 



(I 



[,PROC=ISTj] 

[,update=|st{ 1 



[,RINGCHK= 



k=(yes) 

\no; 



[,USER=TS0 user-id] 
[,ACMAIN=main-name] 



[,ACH0LD= 



(no) 

|YES[^ 



c 
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Defaults: 

SYSTEM=ANY 

HOLD=NO 

JOBSTEP=NOCHKPNT 

TYPE=ANY 

HOTJOB=NO 

JPRTY=JES3 

RINGCHK=YES 

PROC=ST 

EXPDTCHK=YES 

ACHOLD=NO 

If SETUP is not specified, the device requirements for mountable tape and disk volumes is 

based on an initialization parameter. 

• If LINES, CARDS, FETCH, or lORATE are not Specified, the installation default for this job 
class will be used. 

• If CLASS or LREGION are not specified, JES3 will determine the value of LREGION based on 
initialization parameters. 

• If JOURNAL is not specified, JESS will determine the value of JOURNAL based on an 
initialization parameter. 

SYSTEM 

Specifies the processor by name or class of system used for this job. 

• ANY defaults to any system (global, local, or ASP) that satisfies the job's requirements. 

• JGLOBAL specifies that the job is to run on the global processor only. 

• JLOCAL specifies that the job is to run on a local processor only. 

• ASP specifies that the job is to run on any ASP main processor that satisfies the job 
I requirements. The value coded for TYPE must be MVT or VS2/L If TYPE is not coded, the 
I system assumes one of these values. 

• main-name specifies the specific processors considered for this job. 

• /main-name specifies the specific processors excluded from consideration for this job. 

LINES 

specifies the estimated number of lines of data printed for this job. The second group of 
subparameters specifies the action taken when the line estimates are exceeded. 

• nnn is a 3 digit value indicating the number of lines in thousands. 

• WARNING issues an operator warning and continues processing. 

• CANCEL cancels the job. 

• DUMP cancels the job with a storage dump. 

CARDS 

specifies the estimated number of cards punched for this job. The second group of 
subparameters specifies the action taken when the card estimates are exceeded. 

• nnn is a 3 digit value indicating the number of cards in hundreds. 

• WARNING issues an operator warning and continues processing. 
« CANCEL cancels the job. 

• DUMP cancels the job with a storage dump. 

HOLD 

• YES specifies that the job will enter into the system in operator hold status and will be 
withheld from processing until the operator requests its release. This parameter has the 
same function as typrun=hold on the job statement. 

• NO specifies that the job enters the system normally and processing does not require 
operator intervention. 
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SETUP J 

modifies the standard setup algorithm used in assigning devices to a job prior to its i 

execution. 

• JOB indicates that device requirements for mountable units are calculated by the system 
for the entire job. 

• HWS requests allocation of the minimum number of devices required to run the job (high 
watermark setup). 

• THWS requests high watermark setup for tapes and job setup for disks. Job setup 
requests units for every unique volume in the job. 

• DHWS requests high watermark setup for disks and job setup for tape. 

• ddname specifies the DD statements (fully qualified) that are set up before a job enters 
execution (explicit setup). 

• /ddname removes the specified DD statements from consideration for setup (explicit 
setup). 

CLASS 

j specifies the job class for this job. class-name can be 1 to 8 characters. 
FAILURE 

specifies the job recovery option used in case of system failure. This does not apply to 
j continuously active jobs (HOTJOB) on ASP main processors. 

• RESTART restarts the job when the failing processor is restarted. 

• CANCEL cancels the job for printing. 

• HOLD holds the job for restart. 

• PRINT prints the job and then puts the job in hold for restart. 

EXPDTCHK 

I • YES indicates that JES3 Main Device Scheduling (MDS) volume mount verification is to 

perform expiration date checking for scratch SL output tape volumes. ;M 

j • NO indicates that expiration date checking is to be bypassed for this job. 1 

JOURNAL 

I» YES indicates that the job is to have a job journal. 
• NO indicates that the job is to have no job journal. 

JOBSTEP 

specifies the job step checkpoint option for jobs on ASP main processors only. 

• NOCHKPNT stops the checkpoint option. 

• CHKPNT causes a checkpoint to be taken at the end of each job step on the ASP main 
processor. 

TYPE 

specifies the control program used. 

• ANY defaults to any control program (MVT, VS2/1, or VS2) that satisfies the job's 
requirements. 

• MVT specifies the OS/MVT Releeise 21 or later control program in an ASP main processor. 

• VS2/1 specifies the 0S/VS2 Release 1 control program in an ASP main processor. 

• VS2 specifies the 0S/VS2 Release 3 or later control program in a JES3 global or local 
processor. 

NJPCLASS 

specifies that this job is to be placed into an identifiable group of jobs that can be 
transmitted by network job processing, class-name can be 1 to 8 alphameric characters; it 
can be specified as an installation defined NJP terminal name (JES3 global). 
HOTJOB 

• YES specifies a non-ending task scheduled by JES3 on an ASP main processor. 

• NO specifies a job that is not continuously acitve. 
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lORATE 

Specifies the I/O to CPU ratio for a job. This is used in an attempt to balance the mixture of 
jobs selected for execution on the processor. This parameter overrides the installation 
defined job selection criteria for this job's class. 

specifies an override origin group name of the device used to enter the job on the JESS 
system. This parameter causes any output to be directed to the specified origin group. 
Normally, output from a job is directed to the same group of devices from which it 
originated. 
DEADLINE 

specifies when the job is due to be scheduled. 

• time indicates the deadline time. 

- nM specifies that the job is to be scheduled within n minutes, n can range from to 
1440. 

- nH specifies that the job is to be scheduled within n hours, n can range from to 24. 

- hhhh specifies the time of day that the job is to be scheduled, in 24-hour clock time 
(0800 is eight a.m,). hhhh can range from to 2400. 

• type is a single character identifier (A-Z, 0-9), defined by the installation, that specifies 
one of the installation deadUne types. If the type is not defined, the job is flushed. 

• date, in the format MMDDYY for month, day, and year, specifies the date when the time 
parameter takes affect. If the date and rel, cycle is omitted, the current date is assumed 
provided that the current time is earlier than the deadline time. If the current time is 
earlier than the deadline time. If the current time is later, the next day's date is assumed. 

• rel is an integer from 1 to 366 that specifies which day within the cycle the deadline falls. 

- values coded with WEEKLY default to 7 if greater than 7 is specified. Sunday is day 1 ; 
Saturday is day 7. 

- values coded with MONTHLY defauU to 31 if greater than 31 is coded. 29, 30, and 31 
are treated as the last day of the month. 

- values coded with yearly default to 365 for all non-leap years if greater than 365 is 
specified. Leap year defautls to 366. 

• cycle is specified as WEEKLY, MONTHLY, or YEARLY to indicate periodic runs. For 
example, (1, WEEKLY) specifies that the job is to be scheduled Sunday of every week. 

FETCH 

Specifies an override of the installation defined fetch parameter and determines which 
fetch messages will be issued to the operator for disk and tape volumes for this job. 

• ALL specifies that all volumes in DD statements using JESS setup devices, except 
permanently resident volumes, should be fetched. 

• NONE specifies no fetch messages. 

• SETUP specifies that volumes in DD statements specified in the MAIN SETUP parameter 
should be fetched. If no SETUP parameter is specified, the FETCH default is ALL. 

• ddname specifies that only the volumes in the DD statements specified are fetched. 

• /ddname specifies that all volumes in the DD statements specified are not fetched. 

JPRTY 

specifies the execution priority used for a job (for ASP only). 

• JES3 specifies that the job executes using the DPRTY value from the SELECT initialization 
card. 

• JOB specifies that the job uses the PRTY parameter from the JOB statement or the default 
for the job. 

LREGION 

specifies the approximate size of the largest step's working set in real storage during 
execution. LREGION (logical region) is used by JES3 to improve scheduling on a VS2 ASP 
main processor. 
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MAIN 



PROC 

defines the private library searched for the catalog procedure to run the job. 

• ST specifies that the standard default procedure library is searched. 

• XX specifies the last 2 characters of the ddname of the additional procedure library to be 
searched, xx is defined by the installation. 

UPDATE 

defines the procedure library updated by this job. This parameter causes all jobs usmg this 
library to be held until the update is complete. 

• ST specifies that the standard default procedure Ubrary is updated. 

• XX specifies thae last 2 characters of the ddname of the additional procedure Ubrary to be 
updated, xx is defined by the installation. 

RINGCHK 

• YES indicates that a validation check is to be made to determine the correct status of the 
tape reel ring for tape devices set up by JES3. 

• NO indicates that ring checking is to be by-passed for this job. 

USER 

identifies the job with the specified TSO user even though the job was not submitted from 
TSO by that user. This parameter allows: 

• SYSOUT data sets to be sent to an ASP main processor (see ACMAIN) for use by the TSO 
user. 

• the TSO user on an MVS processor (global or local) to access SYSOUT data sets with the 
TSO OUTPUT command. 

• the TSO user on any processor to inquire about the status of the job or to cancel the job. 

ACMAIN 

identifies the job with the specified processor even though the job was not submitted from 
or executed on that processor. This parameter allows: 

• SYSOUT data sets to be sent to the ASP main processor (see USER). 

• the job termination message IAT6108 to be sent to the processor if the NOTIFY 
parameter was coded on the JOB card. 

ACHOLD 

specified the disposition of SYSOUT data sets which have been routed to a TSO user on an 
ASP main processor. 

• NO allows the data sets to be printed or punched immediately after being sent to the 
main processor. 

• YES prevents the data sets from being printed or punched until the associated TSO user 
(MVT or VS2-1 only) issues a RELEASE command for the job. 

Rules for Coding TYPE and SYSTEM 

• If the TYPE control program requested is not active on the system, the job will wait 
indefinitely until the control program is active. 

• If the control program is inconsistent with the SYSTEM parameter, the job will be flushed. 

I For example SYSTEM=ASP,TYPE=VS2 will not run. It must also be consistent with PROCESS 
statements. 
• You do not always need to code either the TYPE or SYSTEM parameters because the 
installation often estabUshes defaults according to job class. Check this with the system 
programmer. 

Rule for Coding LINES 

LINES =0 only apphes to jobs in the execution phase. After the first line is sent out for writing, 
the job will issue a warning, a cancel, or a dump, depending on what is requested. When 
printing the output, however, LINES =0 is ignored. 



i 
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Rule for Coding CARDS 



CARDS=0 only applies to jobs in the execution phase. After the first line is sent for punching, 
the job will issue a warning, a cancel, or a dump, depending on what is requested. When 
punching the output, however, CARDS =0 is ignored. 



Rule for Coding SETUP 



When specif3mig ddname, enough devices must be specified to allow JES3 allocation for the 
maximum number of devices required at any one time. If specified devices are insufficient, the 
job is canceled. 

Rules for Coding CLASS 

• If a single character class-name is used, it may be specified on the JOB statement. 

• A valid CLASS parameter on the MAIN statement overrides a valid CLASS parameter on the 
JOB statement. 

Rule for Coding FAILURE 

FAILURE is ignored if HOTJOB is coded. 



Rule for Coding EXPDTCHK 



If EXPDTCHK=YES, the SL tape scratch requests that are pre-mounted by MDS must have 
expired labels. 

Rule for Coding JOURNAL 

The JOURNAL parameter overrides what was specified on the CLASS card of the JES3 
initiaUzation deck. 

Rule for Coding NJPCLASS 

The operator can initiate transmission of the entire group of jobs with one operator command 
rather than entering a separate command for each individual job. 

Rules for Coding HOTJOB (for ASP main processors only) 

• If a JES3 system failure occurs while a continuously active job is executing, JES3 can be 
restarted without interrupting its execution. 

• If the continuously active jobs are using JES3 setup, the allocated devices will be reserved 
over a JES3 restart. As a result, there are no rescheduhng requirements for these jobs after a MAir 
JES3 restart. 

• Continuously active jobs cannot use SYSIN or SYSOUT (if JES3 or ASP processes them), or 
run on global or local processors. The HOTJOB parameter is ignored for jobs scheduled on 
MVS processors. 



^^ 



Rules for Coding ORG 



The FORMAT statement will override the ORG parameter if specified for the particular data 

set. 

The MAIN ORG statement should precede all FORMAT statements that do not contain the 

DEST parameter. If it does not, the default for these data sets is where the job entered the 

system. 
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Rule for Coding DEADLINE 



If the current date is specified and the job is submitted after the deadline time, all of the 
priority changes are applied to make the job the same priority level it would have been if it 
had been submitted prior to the deadline and not completed. 



Rules for Coding JPRTY 



• If the parameter is omitted or if JES3 is specified, the execution priority is assigned from the 
DPRTY value on the SELECT statement. 

• Job priority is changed after job selection but before job execution. Therefore the original 
priority is used for job selection and for any post-execution processing. 

• PRTY does not apply to job execution. JPRTY overrides the prty field and establishes job 
execution priority if JPRTY=jes3. 



Rule for Coding LREGION 



Consult the system programming staff for guidance in using the LREGION parameter. If the 
values selected for LREGION are too small, the job may run slower. 



Rule for Coding PROC 



If a procedure is specified for which there is no corresponding PROCLIB entry, the job is 
flushed. 



Rules for Coding UPDATE 



If a procedure is specified for which there is no corresponding PROCLIB entry, the job is 

flushed. 

If this parameter is specified for a job requesting NJP processing, the job is flushed. 



Rule for Coding ACMAIN 



When used for SYSOUT data sets, this parameter applies to all eligible output of the job. 
However, it can be overridden for a specific data set with the main parameter on a FORMAT 
AC statement for that data set. 



Rule for Coding ACHOLD 



This parameter applies to all eligible output of the job. However, if can be overridden for a 
specific data set with the HOLD parameter on a FORMAT AC statement for that data set. 
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Examples of the MAIN Statement 

//*MAIN SYSTEM=SY1 ,LINES=( 5 , C ) , SETUP^HWS , 
//*FAILURE=RESTART,DEADLINE=(0800,A,3,WEEKLY) 

The job executes on system SYl. It is estimated to produce 5000 lines of printed output and if 
the output exceeds 5000 lines, the job is canceled. HWS specifies that a minimum number of 
devices required for this job is allocated. In the event of a system failure, the job is restarted 
I on the main processor SYl. JES3 attempts to complete this job by 8 a.m. every Tuesday 
(Tuesday is day number 3) by adjusting the job's scheduling priority using the 
installation-defined A type deadline scheduling parameters. 

//*MAIN TYPE=VS2/1 ,HOLD=YES ,CLASS=TEST1 , FAILURE=CANCEL 

The job executes on an ASP main processor that is using 0S/VS2 Release 1 as its control 
program. The job is initially placed in hold status until the operator requests its release. The 
job is assigned to a class called TESTl. TESTl must be installation-defined and must support an 
ASP main processor. Job selection is based on the priority of class TESTl. In the event of 
system failure, the job is canceled. 



^^g 
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The NET Statement 



( 



Control Statement 

The NET statement defines the dependencies between jobs in a dependent job-net. 
For more information, see "Dependent Job Control" earlier in this book. 



\ NHOLD I 



//♦NET j NETID ) 

ID ) =name 

NHOLD 

HC 

RELEASE ) 
/ RL ^=( jobnamel , jobnaine2, 
( NORMAL I (D) 

JNC J =Jf| ] 

j ABNORMAL) 

Jab }=<(f ;> ] 



jobnamen )] 



'■'■ll\ 



i -!"' 



YES^] 
=n] 
( netid, jobname )] 



S OPHOLD 
J OH 
JRELSCHCT) 

}rs \ 

JNETRELi 
]NR S 

(ANY) 
DEVPOOL=( I NET 5 , device-name, number [ , device-name, number, 

(YES[ 
DEVRELSE=JNO (] 



Defaults: NORMAL=D 

ABNORMAL=R 
OPHOLD=NO 
DEVPOOL=ANY 
DEVRELSE=NO 
NETID 

specifies the name of the job-net containing this job. name can be from 1 to 8 characters; 
the first character must be alphabetic, 
NHOLD 

specifies the number of immediate predecessor job completions required before this job can 
be released for scheduling, n can range from 1 to 32,767. 
RELEASE 

Specifies the jobnames of jobs in the specified job-net that are successors to this job. 
NORMAL and ABNORMAL 

Specifies the action taken for this job when any predecessor normally or abnormally 
completes execution. 

• D means decrement the NHOLD count (the number of predecessors) of this job. If the 
NHOLD count goes to zero, this job becomes eligible for scheduling. 

• F means flush the job and its successors from the system. The job is canceled, any output 
printed, and all successors canceled regardless of their normal or abnormal specifications. 



< 



• R means retain this job in the system and do not de 



vuO! rs f"rsi 



suspends the job and its successors from scheduling until either the precedessor job is 
resubmitted or the operator decreases the NHOLD count. 
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OPHOLD 

• NO Specifies that the job is to be processed normally without operator intervention. 

• YES specifies that the job is placed in DJC operator hold. This prevents scheduling of this 
job until it is explicitly released from DJC operator hold by the operator. 

RELSCHCT 

controls early set up of a dependent job's resources, n can range from 1 to 32,767. Set up 
begins when the NHOLD count becomes less than or equal to n. 
NETREL 

Specifies that this job is a predecessor to a job in another job-net. 

• netid identifies the NETID name of the successor job. 

• jobname identifies the name of the successor job. 

DEVPOOL 

specifies devices to be dedicated to this dependent job control net. 

• ANY indicates that jobs in the net can use any dedicated or non-dedicated device. 

• NET indicates that jobs can use only devices dedicated to the net. 

• device-name and number indicates the name and number of dedicated devices, 
device-name can be an installation defined name (names defined to JES3 by the 
installation), or any name specified in the UNIT parameter except unit address, number 
can range from 1 to 32,767. 

DEVRELSE 

• YES specifies that all devices dedicated to the dependent job control net should be 
released at the end of this job. 

• NO specifies that aU dedicated devices are released when the last job in the net ends. 



General Rules for Coding 



Only one NET statement can be defined for each job of a job-net. 

The parameters on the NET statement can be coded in any order. 

The RELEASE parameter is the only parameter on the NET statement that can be split and 

continued. 



Rules for Coding NETID 



• All jobs put into the system with the same NETID name form a dependent job control (DJC) 
net. 

• NETID names must be unique within the JES3 system. A job that has the same NETID name 
as an existing job-net is added as a member of that job-net. 



^^g 



Rules for Coding NHOLD ^^^ 

• If n is zero or is not specified, then this job has no predecessors and is immediately eUgible 
for scheduling. 

• If an incorrect NHOLD count is specified, two situations can occur: 

1. If n is greater than the actual number of predecessor jobs, then this job is not released 
from DJC hold when all of its predecessors complete execution. 

2. If n is less than the actual number of predecessor jobs, this job is prematurely released 
from DJC hold. 

Rules for Coding RELEASE 

• From 1 to 50 successor jobnames can be specified. 

• RELEASE values can be split on a NET continuation statement. 



Coding JES3 Control Statements 301 



Rules for Coding RELSCHCT 

• If n is zero or is not specified, there is no early set up of dependent jobs. 

• This parameter must not be specified for a job that may have catalog dependencies in 
dependent job control. 

I» Do not specify RELSCHCT for nonstandard DJC jobs. Nonstandard DJC jobs are explained in 
the section, "The PROCESS Statement". 

Rule for Coding NETREL 

The NETREL parameter can be specified only once for each job of a given job-net. 

Rules for Coding DEVPOOL 

This parameter is only recognized when found in the first job of a job-net entered into the 

system. 

The first subparameter indicates what devices are eligible for volume mounting by jobs in 

the net. If ANY is specified, allocation is attempted from the dedicated pool before any 

non-dedicated devices are used. 

The device-name and number can be repeated for additional devices eligible for volume 

mounting up to a maximum that will fit on one card. 

Rule for Coding DEVRELSE 

This parameter can be specified on one or more jobs in the net. The first completing job that 
has specified DEVRELSE=YES causes the devices dedicated to the net to be released. 

I 

Examples of the NET Statement 

//*NET ID=NET01 ,NHOLD=0 , AB=F,DEVPOOL=( ,3330,2 ) 

Defines a job-net named NETOl. There are no predecessor jobs. In the event the job fails, all 
successor jobs in NETOl are flushed. The DEVPOOL parameter (which must be coded with the 
first job in the net) requests a device pool of two 3330s to be established for the job-net. 

//*NET ID=N1 ,RL=B,NR={N2,B2 ),DEVPOOL=(NET,3330,1 ) 

Defines a job-net named NL This job is a predecessor of job B, which is in Nl, and job B2, 
which is in the job-net named N2. The RL parameter releases job B; the NR parameter releases 
job B2. The DEVPOOL parameter specifies that one 3330 is to be dedicated to this job-net; 
jobs in the net must wait for the availability of this device if it is in use. 



i 
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The OPERATOR Statement 



Control Statement 



The OPERATOR statement transmits any desired message to the operator. Columns 1 through 
80 are sent to the LOG console when the job enters the JES3 queue. 



r 



//♦OPERATOR text 



Example of the OPERATOR Statement 

//♦OPERATOR CALL EXT. 641 WHEN THIS JOB STARTS 




NET 
MAII 
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The PAUSE Statement 



Control Statement 



An input reader can be halted temporarily by punching the psuedo command, PAUSE, starting 
in column 5. The PAUSE statement can be entered through any reader. The reader then issues 
a message and waits for operator reply. The use of the PAUSE statement is intended primarily 
for system checkout and test. It is recognized only if submitted before the JOB statement in the 
input stream. It is recommended for remote users only. 



r 



//** PAUSE 



Rules for Coding 



At least two blanks must follow the word PAUSE before comments are added. 
The PAUSE statement can be entered through any reader. 



Example of the PA USE Statement 

//♦♦PAUSE 



\ 
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The PROCESS Statement 



Control Statement 



The use of the PROCESS statement causes JES3 to bjnpass its standard job flow. Any job that 
includes PROCESS statements receives only the JESS processing specified on the PROCESS 
statements, except that which JESS must perform. By using one or more PROCESS statements, 
you can bypass JESS job execution or bypass JESS output processing, or both. Bypassing 
execution allows checking the JCL of a job, and bypassing output processing permits the 
operator to check (by inquiry command) whether the job reaches execution. 



The PROCESS statement can also be used to call any Dynamic Support Program (DSP) that is 
defined in the DSP dictionary as being able to be processed. 

//♦PROCESS dsp 



r 



DSP 

Specifies the name of the DSP that is to be processed. Figure 28 lists the valid DSP names 
and whether parameters can follow. 



Rules for Coding 



Each PROCESS statement can have only one operand, which is the name of a dsp. Figure 

28 lists the permissible DSPs. 

If the DSP requires specification of parameters, these parameters are listed on the next card, 

starting in column 1, separated by commas. Parameters required and optional with each 

utility DSP are given in Operator's Library: OS/VS2 Reference (JES3). 

Several PROCESS cards may follow each other or be separated by parameters that apply to 

the preceding PROCESS card. JESS accomplishes the processing for the PROCESS cards in the 

order they appear in the input stream. 



^^» 



PAUSE 
PROCES 
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Examples of the PROCESS Statement 



i 



//EXAM1 


JOB 


//♦PROCESS 


CI 


//♦PROCESS 


MAIN 


//♦PROCESS 


OUTSERV 


//SI 


EXEC 



remaining JCL statements 

This is an example of submitting a simple job via //*PROCESS statements. It executes the 
same as a standard job without JES3 control statements. Four scheduler elements are created 
for the job. The CI DSP creates the control blocks for MAIN, the next scheduler element. The 
OUTSERV DSP is scheduled after MAIN completion. PURGE is the last function in any job, and 
has a scheduler element created automatically. 



//EXAM2 


JOB 


//♦PROCESS 


CI 


//♦PROCESS 


MAIN 


//♦PROCESS 


OUTSERV 


//♦PROCESS 


PLOT 


//♦PROCESS 


TT 



IN=( TA9 ) , MDI=T , ID=DEP836 , FILES=2 
//♦ENDPROCESS 
//S 1 EXEC 

//DD1 DD UNIT=24009,DISP=( NEW, KEEP) 

remaining JCL statements 

This an example using user-written DSPs and JESS utilities. PLOT is a user-written DSP and is to 

be executed after output service has completed. The TT DSP is a tape-to-tape utility and is 

followed by the parameters needed for it to be used. A 

//EXAM3 JOB 

//♦PROCESS OUTSERV 

//♦FORMAT PR,DDNAME=DS1 ,C0PIES=5 

//♦DATASET DDNAME=DS 1 

any data 
//♦ENDDATASET 

This example uses JES3 output service and the DATASET statement. Five copies of data set DSl 
are printed on any local (not remote) printer. 
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Reference Tables 



The first section of this appendix summarizes the DD statement parameters required to perform 
the following functions: 

Create a data set on an unit record device (card punch or printer) 

Create a data set on a system output device 

Create a data set on magnetic tape 

Create a data set on a direct access device 

Retrieve a data set fron an unit record device (card reader or paper tape reader) 

Retrieve a data set from the input stream 

Retrieve a passed data set (magnetic tape or direct access) 

Retrieve a cataloged data set (magnetic tape on direct access) 

Retrieve a kept data set (magnetic tape or direct access) 

Extend a passed data set (magnetic tape or direct access) 

Extend a cataloged data set (magnetic tape or direct access) 

Extend a kept data set (magnetic tape or direct access) 

Also included are tables for: 

retrieving or extending an Indexed Sequential Data Set 

area arrangement of Indexed Sequential Data Sets 

mutually-exclusive DD parameters 

disposition processing 

direct access capacities 

track capacities 

allowable DSPs for PROCESS Statements 

character arrangement tables for the 3800 

the JOB statement 

the EXEC statement 

the DD statement 
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Device 


Parameter Type 


Parameter 


Comments 


Unit 

Record 

Devices 


Location of the Data Set 


UNIT 


Required 


Data Attributes 


DCB 


Optional 


Special Processing Options 


UCS 


Optional (for a printer with the universal character set feature) 


FCB 


Optional (for a 321 1 or 3800 printer if forms control information 
is to be specified) 


FREE 


Optional 


DUMMY 


Optional 


COPIES 


Optional 


CHARS 


Optional (for the 3800 Printing Subsystem) 


BURST 


Optional (for the 3800 Printing Subsystem) 


FLASH 


Optional (for the 3800 Printing Subsystem) 


MODIFY 


Optional (for the 3800 Printing Subsystem) 


System 
Output 
Devices 


Location of the Data Set 


SYSOUT 


Required. Specifies the output class 


Data Attributes 


DCB 


Optional 


Special Processing Option 


OUTLIM 


Optional 


FREE 


Optional 


DEST 


Optional 


DSID 


Required for output to a 3540 diskette 


HOLD 


Optional 


UCS 


Optional (for a printer with the universal character set feature) 


FCB 


Optional (for a 321 1 or 3800 printer if forms control information 
is to be specified) 


COPIES 


Optional 


CHARS 


Optional (for the 3800 Printing Subsystem) 


BURST 


Optional (for the 3800 Printing Subsystem) 


FLASH 


Optional (for the 3800 Printing Subsystem) 


MODIFY 


Optional (for the 3800 Printing Subsystem) 


l\^agnetic 
Tape 


Data Information 


DSNAME 
(or DSN) 


Required if the data set is to be cataloged or used by a later job 


DISP 


Required if the data set is to be cataloged, used by a later step in this 
job, or used by another job 


Location of the Data Set 


UNIT 


Required unless you request (with the VOLUME parameter) the same 
volume used for an earlier data set in your job 


VOLUME 
(or VOL) 


Required if you want a specific volume. If you do not use this 
parameter you will get a scratch tape 


LABEL 


Required if you do not want to use IBM standard labels for the data set 


Data Attributes 


DCB 


Optional 


Special Processing Options 


DUMMY 


Optional 


CHKPT 


Optional 


FREE 


Optional 



i 



i 



Figure 19. DD Parameters for Creating a Data Set (Part 1 of 2) 
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Device 


Parameter Type 


Parameter 


Comments 


Direct 
Access 
Devices 


Data Set Information 


DSNAME 
(or DSN) 


Required if the data set is to be cataloged or used by a later job 


DISP 


Required if the data set is to be cataloged, used by a later step in this 
job, or used by another job 


Location of the Data Set 


UNIT 


Required unless you request (with the VOLUME parameter) the same 
volume used for an earlier data set in your job 


VOLUME 
(or VOL) 


Required if you want a specific volume or multiple volumes. If you do 
not use this parameter your data set will be allocated on any suitable 
volume 


LABEL 


Required if you want the data set to hgve both IBM standard 
and user labels 


Size of the Data Set 


SPACE 


SPACE must be used for ISAM data sets 


Data Attributes 


DUMMY 


Optional 


DYNAM 


Optional 


FREE 


Optional 



Figure 19. DD Parameters for Creating a Data Set (Part 1.1 of 2) 
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Device 


Parameter Type 


Parameter 


Comments 


Mass 
Storage 
System 
(MSS) 


Data Set Information 


DSNAME 
(or DSN) 


Required if the data set is to be cataloged or used by another job 


DISP 


Required if the data set is to be cataloged, used by a later step in the 
job, or used by another job 


Location of Data Set 


UNIT 


Required unless you request (with the VOLUME parameter) 
the sanne volume used for an earlier data set in your job 


VOLUME 
(or VOL) 


Required for specific volume requests. Use MSVGP instead of 
VOL=SER if a nonspecific volume in a specific MSS volume group is 
desired. If neither is coded, the system will select an already mounted 
3330V volume (storage or public) unless PRIVATE is coded 


LABEL 


Required if you want the data set to have both IBM standard and 
user labels 


MSVGP 


Required if a nonspecific volume in a specific MSS volume group is 
required 


Size of Data Set 


SPACE 


Required unless MSVGP is coded 


Data Attributes 


DUMMY 


Optional 


DYNAM 


Optional 


FREE 


Optional 



Figure 19. DO Parameters for Creating a Data Set (Part 2 of 2) 
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Data Set 


Parameter Type 


Parameter 


Comments 


Unit 

Record 

Devices 


Location of the Data Set 


UNIT 


Required 


Data Attributes 


DCB 


Optional 


Special Processing Option 


DUMMY 


Optional 


FREE 


Optional 


Input 
Stream 


Location of the Data Set 


* 


You must specify one of these parameters 


DATA 


Special Processing Option 


DLM 


Optional 


FREE 


Optional 


Associated 
Data Set 


Location of Data Set 


* 


You must specify one of these parameters 


DATA 


Data Set Information 


DSID 


Required for 3540 associated data sets 


VOL=SER 


Optional for 3540 associated data sets 


Passed 
Data Set 


Data Set Information 


DSNAME 


Required 


DISP 


Required 


Location of the Data Set 


UNIT 


Required only if you want more units 


LABEL 


Required only if the data set does not have IBM 
standard labels 


Data Attributes 


DCB 


Optional 


Special Processing Option 


FREE 


Optional 


CHKPT 


Optional 


DUMMY 


Optional 


Cataloged 
Data Set 


Data Set Information 


DSNAME 


Required 


DISP 


Required 


Location of the Data Set 


UNIT 


Optional 


VOLUME 


May be required if you want to begin processing with a 
volume after the first 


LABEL 


Required only if the data set does not have IBM 
standard labels 


Special Processing Options 


DUMMY 


Optional 


DYNAM 


Optional 


FREE 


Optional 


CHKPT 


Optional 


Kept 
Data Set 


Data Set Information 


DSNAME 


Required 


DISP 


Required 


Location of the Data Set 


UNIT 


Required 


VOLUME 


Required 


LABEL 


Required only if the data set does not have IBM 
standard labels 


Data Attributes 


DCB 


Optional 


Special Processing Options 


DUMMY 


Optional 


DYNAM 


Optional 


FREE 


Optional 


CHKPT 


Optional 



i 



i 



Figure 20. DD Parameters for Retrieving a Data Set 



i 
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Data Set 


Parameter Type 


Parameter 


Comments 


Passed 
Data Set 


Data Set Information 


DSNAME 


Required 


DISP 


Required 


Location of the Data Set 


UNIT 


Required only if you want more units 


VOLUME 


Required only if you need more volunnes 


LABEL 


Required only if the data set does not have IBM standard 
labels 


Size of the Data Set 


SPACE 


Required only if you want to override the secondary quantity 


Data Attributes 


DCB 


May be required if data set does not have IBM standard labels 


Special Processing Option 


FREE 


Optional 


CHKPT 


Optional 


DUMMY 


Optional 


Cataloged 
Data Set 


Data Set Information 


DSNAME 


Required 


DISP 


Required 


Location of the Data Set 


UNIT 


Optional 


VOLUME 


Required only if you need more volumes 


LABEL 


Required only if the data set does not have IBM standard 
labels 


Size of the Data Set 


SPACE 


Required only if you want to override the secondary quantity 


Data Attributes 


DCB 


Required only if the data set does not have IBM standard 
labels 


Special Processing Options 


DUMMY 


Optional 


FREE 


Optional 


CHKPT 


Optional 


Kept 
Data Set 


Data Set Information 


DSNAME 


Required 


DISP 


Required 


Location of the Data Set 


UNIT 


Required 


VOLUME 


Required 


LABEL 


Required only if data set does not have IBM standard labels 


Size of the Data Set 


SPACE 


Required only if you want to override the secondary quantity 


Data Attributes 


DCB 


Required only if the data set does not have IBM standard 
labels 


Special Processing Options 


DUMMY 


Optional 


DYNAM 


Optional 


FREE 


Optional 


CHKPT 


Optional 



Figure 21. DD Parameters for Extending a Data Set 
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Area 


Parameter Type 


Parameter 


Comments 


Index (used only if 
index area not on same 
device type as prime 
area) 

(First DD statement) 


Data Set Information 


DSNAME 


Required, You must code the same value 
as in second DD statement. 


DISP 


Required. You must code the same value 
as in second DD statement. 


Location of the data 
set 


UNIT 


Required 


VOLUME 


Required 


Data Attributes 


DCB 


Required 


Prime and Overflow; 
or Index, Prime, and 
Overflow; or Index 
and Prime (required) 

(Second DD 
statement ) 


Data Set Information 


DSNAME 


Required 


DISP 


Required. Specifies whether you are 
retrieving the data set. 


Location of the data 
set 


UNIT 


Required unless it is a passed data 

set with all three areas on one volume. 


VOLUME 


Same requirement as UNIT. If used, 
code volumes in order they were defined. 


Data Attributes 


DCB 


Required 


Overflow (used only 
if overflow area not 
on same device type 
as prime area) 

(Third DD Statement) 


Data Set Information 


DSNAME 


Required. You must code the same 
value as in second DD statement. 


DISP 


Required. You must code the same 
value as in the second DD statement. 


Location of the data 
set 


UNIT 


Required 


VOLUME 


Required 


Data Attributes 


DCB 


Required 



i 



Figure 22. DD Parameters for Retrieving or Extending m Indexed Squential Data Set 
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CRITERIA 


RESTRICTIONS ON DEVICE 
TYPES AND NUMBER OF 
DEVICES REQUESTED 


RESULTING 
ARRANGEMENT OF 
AREAS 


1 . Number of DD 
statements 


2. Area defined on a 
DD statement 


3. Index size 
coded ? 


3 


INDEX 
PRIME 
OVFLOW 


- 


None 


Separate index, prime, 
and overflow areas. 


2 


INDEX 
PRIME 


- 


None 


Separate index and 
prime areas. 


2 


PRIME 
OVFLOW 


No 


None 


Separate prime and 
overflow areas. An 
index area is at the end 
of the overflow area. 


2 


PRIME 
OVFLOW 


Yes 


The statement defining 
the prime area cannot 
request more than one 
device. 


Separate prime and 
overflow areas. An 
index area is embedded 
in the prime area. 


1 


PRIME 


No 


None 


Prime area with index 
area at its end.^ 


1 


PRIME 


Yes 


Cannot request more 
than one device. 


Prime area with 
embedded index area. 


^ If both areas are on volumes that con-espond to the same device type, an overflow area is established if one of the 
cylinders allocated for the index area is only partially used. The overflow area is established in the unused 
portion of that cylinder. 

If the unused portion of the index area is less than one cylinder, it is used as an overflow area. 



Figure 23. Area Arrangement of Indexed Sequential Data Sets 
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Legend: This table shows which DO parameters cannot be coded together. 
At the intersection of the horizontal and vertical colunnns, the square will 
be black if the parameters are mutually exclusive and white if they can be 
coded together on the same DD statement. 

For example, to see if DISP and SYSOUT are mutually exclusive, look 
down the column marked DISP and across the column marked SYSOUT. 
In this case, they are mutually exclusive. 

As indicated by the table, each DD parameter is mutually exclusive with 
itself; that is, it cannot appear twice on the same DD statement. 

Figure 24. Table of Mutually Exclusive DD Parameters 



314 OS/VS2 JCL(VS2.03.810) 



Status 


Requested Disposition 


Conditional Disposition 


Action Taken 




Action Taken at Abnormal End of Step ' , 
when Step Fails Due to: 


Action Taken at 
End of Job 


at Normal 
End of Step 


Program canceled or 
abnormally terminated 


Subsequent data set allocation 
for same step failed 


NEWorMOD^ 


none 


none 


deleted 


deleted 


deleted 




KEEP 


none 


kept 


kept 


deleted 




DELETE 


none 


deleted 


deleted 


deleted 




CATLG 


none 


cataloged 


cataloged 


deleted 




PASS 


none 


passed 


passed 


passed 


deleted 


PASS 


any 


passed 


passed 


passed 


deleted^ 


any except PASS 


KEEP 


requested disposition 


kept 


deleted 




any except PASS 


DELETE 


requested disposition 


deleted 


deleted 




any except PASS 


CATLG 


requested disposition 


cataloged 


deleted 




OLD or MOD 
or SHR 


none 


none 


kept 


kept 


kept 




KEEP 


none 


kept 


kept 


kept 




DELETE 


none 


deleted 


deleted 


kept 




CATLG 


none 


cataloged ^ 


cataloged'' 


kept 




UNCATLG 


none 


uncataloged 


uncataloged 


kept 




PASS 


none 


passed 


passed 


passed 


kept 


PASS 


any 


passed 


passed 


passed 


kept® 


any except PASS 


KEEP 


requested disposition 


kept 


kept" 




any except PASS 


DELETE 


requested disposition 


deleted 


kept" 




any except PASS 


CATLG 


requested disposition 


cataloged^ 


kept" 




any except PASS 


UNCATLG 


requested disposition 


uncataloged 


kept" 




Footnotes: 

^ See list of exceptions in right-hand column. 

2 If volume information is not available to the system, a MOD data set is considered 
to be a new data set. 

^ If votumes were added to a data set for which unit and volume information was 
retrieved from the catalog, the data set is actually recataloged. 

^ If the step was attempting to receive a passed data set which was new when 
initially passed, the data set is deleted. 

^ If any job steps reached abnormal termination, the conditional disposition will 
be processed. Otherwise, the data set is deleted. 

^ If any job steps reached abnormal termination, the conditional disposition will 
be processed. Otherwise, the data set is kept if it was old when initially passed 
in the job, or deleted if it-was new when originally passed in the job. 


List of Exceptions: 

• When a nontemporary data set is passed and the receiving step does not assign it a 
disposition, the system will, upon termination of this step, do one of two things. 
If the data set was new when it was initially passed, it will be deleted. If the 
data set was old when initially passed, it will be kept. Temporary data sets are 
deleted. 

• If automatic step restart is to occur, all data sets in the restart step with a status 

of OLD are kept. All data sets in the restart step with a status of NEW are deleted. 

• If automatic checkpoint restart is to occur, all data sets currently in use by the 
[ob are kept. 

• If a data set is assigned a temporary name or no name, a conditional disposition 
other than DELETE is invalid. The system assumes DELETE. 

• If a tape data set is unopened, it receives no disposition processing. 

• if the data set is not allocated, then no action Is taken. 



Figure 25. Disposition Processing Chart 




Device 


2314/2319 
(each volume) 


2305 


3330 


3330 Mod II 


3340/3344 


3350 


Storage Medium 


Disk 


Disk 


Disk 


Disk 


Disk 


Disk 


Cylinders 


200 


Model 1: 48 
Model 2: 96 


404 


808 


696 (70-megabytes) 
348 (35-megabytes) 


555 


Tracks Per Cylinder 


20 


8 


19 


19 


12 


30 


Bytes Per Track 


7,294 


Model 1: 14,136 
Model 2: 14,660 


13,030 


13,030 


8368 


19,069 


Bytes Per Cylinder 


145,880 


Model 1: 113,068 
Model 2: 117,280 


247,570 


247,570 


100,416 


572,070 


Bytes Per Device 
(in millions) 


29.17 


Model 1: 5.4 
Model 2: 11.3 


101.6 


201.7 


69.8 (70-megabytes) 

34.9 (35-megabytes) 


317.5 



I 



Note: 3344 pertains only to the 70-megabyte 3340 
Figure 26. Direct Access Capacities 



Maximum Bytes per Record Formatted without Keys 


Records 

per 

Track 


Maximum Bytes per Record Formatted with Keys 


2314/ 
2319 


2305-1 


2305-2 


3330/ 
3330 Mod II 


3340/ 
3344 


3350 


2314/ 
2319 


2305-1 


2305-2 


3330/ 
3330 Mod II 


3340/ 
3344 


3350 


7294 
3520 
2298 
1693 
1332 


14136 
6852 
4424 
3210 
2480 


14660 
7231 
4754 
3516 
2773 


13030 
6447 
4253 
3156 
2498 


8368 
4100 
2678 
1966 
1540 


19069 
9442 
6233 
4628 
3665 


1 
2 
3 
4 
5 


7249 
3476 
2254 
1649 
1288 


13934 
6650 
4222 
3008 
2278 


14569 
7140 
4663 
3425 
2682 


12974 
6391 
4197 
3100 
2442 


8293 
4025 
2603 
1891 
1465 


18987 
9360 
6151 
4546 
3583 


1092 
921 
793 
694 
615 


1996 
1648 
1388 
1186 
1024 


2278 
1924 
1659 
1452 
1287 


2059 
1745 
1510 
1327 
1181 


1255 
1052 
899 
781 
686 


3024 
2565 
2221 
1954 
1740 


6 
7 
8 
9 
10 


1049 
877 
750 
650 
571 


1794 

1446 

1186 

984 

822 


2187 
1833 
1568 
1361 
1196 


2003 
1689 
1454 
1271 
1125 


1180 
977 
824 
706 
611 


2942 
2483 
2139 
1872 
1658 


550 
496 
450 
41-1 
377 


892 
782 
688 
608 
538 


1152 
1040 
944 
863 
792 


1061 
962 
877 
805 
742 


608 
544 
489 
442 
402 


1565 
1419 
1296 
1190 
1098 


11 
12 
13 
14 
15 


506 
452 
407 
368 
333 


690 
580 
486 
406 
336 


1061 
949 
853 
772 
701 


1005 
906 
821 
749 
686 


533 
469 
414 
367 
327 


1483 
1337 
1214 
1108 
1016 


347 
321 
298 
276 
258 


478 
424 
376 
334 
296 


730 
676 
627 
584 
544 


687 
639 
596 
557 
523 


366 
335 
307 
282 
259 


1018 
947 
884 
828 
777 


16 

17 
18 
19 
20 


304 
277 
254 
233 
215 


276 
222 
174 
132 
94 


639 
585 
536 
493 
453 


631 
583 
540 
501 
467 


291 
260 
232 
202 
184 


936 
865 
802 
746 
695 


241 
226 
211 
199 
187 


260 
230 
200 
174 
150 


509 
477 
448 
421 
396 


491 
463 
437 
413 
391 


239 
220 
204 
188 
174 


731 
690 
652 
617 
585 


21 
22 
23 
24 
25 


198 
183 
168 
156 
144 


58 


418 
386 
357 
330 
305 


435 
407 
381 
357 
335 


164 
145 
129 
113 
99 


649 
608 
570 
535 
503 


176 
166 
157 
148 
139 


128 
106 
88 
70 
52 


373 
352 
332 
314 
297 


371 
352 
335 
318 
303 


161 
149 
137 
127 
117 


555 
528 
502 
478 
456 


26 
27 
28 
29 

30 


133 
123 
114 
105 
96 




282 
261 
241 
223 
206 


315 
296 
279 
262 
247 


86 
74 
62 
52 
42 


473 
446 
420 
396 
374 



'iguie 27. Track Capacities 
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DSP 


DSP Function 


Parameters 


DR 


Disk Reader 


Yes 


Rl 


OS Reader/Interpreter 


Yes 


CI 


MVS Converter/Interpreter 


Yes 


OUTSERV 


Output Service 


Yes 


NJPIO 


Network Job Processing 


Yes 


CC 


Card to Card 


Yes 


CP 


Card to Printer 


Yes 


CT 


Card to Magnetic Tape 


Yes 


DISPLAY 


Display Job Queues 


No 


TD 


Tape Dump 


Yes 


TL 


Tape Label 


Yes 


TC 


Tape to Card 


Yes 


TP 


Tape to Printer 


Yes 


TT 


Tape to Tape 


Yes 


JESNEWS 


Use JESNEWS Facility 


Yes 


ISDRVR 


Input Service Driver (JES3 Control Card Processing) 


Yes 


CBPRNT 


Control Block Print 


Yes 


DISPDJC 


Display Dependent Job Control 


Yes 



Figure 28. Table of AiowaUe DSPs for PROCESS Statements 
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System 


Character 






Number of 


Generation 


Arrangement 






Graphic 


Group 


Table Names 


Character Set 


Pitch ^ 


Characters 


Basic 


GS10 


Gothic-10 


10 


63 


group 


GS12 


Gothic-12 


12 


63 




GS15 


Gothic- 15 


15 


63 




GSC 


Gothic-15 condensed 


15 


63 




GF103 


Gothic-10 -folded 


10 


62 




GF123 


Gothic-12 -folded 


12 


62 




GF15^ 


Gothic-15 -folded 


15 


62 




GFC^ 


Gothic-15 condensed - folded 


15 


62 




GU10 


Gothic-10 - underscored 


10 


63 




GU12 


Gothic-12 - underscored 


12 


63 




GU15 


Gothic-15 - underscored 


15 


63 




GUC 


Gothic-15 condensed - underscored 


15 


63 




TUIO'^ 


Text 1 8i 2 - underscored 


10 


120 




DUMP* 


Gothic-15 & underscored Gothic-15 


15 


79 


3211 


All 


Gothic-10 


10 


48 


group 


Gil 


Gothic-10 


10 


63 




H11 


Gothic-10 


10 


48 




P11 


Gothic-10 


10 


60 




Til* 


Text 1 & 2 


10 


120 


1403 


AN 


Gothic-10 


10 


48 


group 


GN 


Gothic-10 


10 


63 




HN 


Gothic-10 


10 


48 




PCAN 


Gothic-10 


10 


48 




PCHN 


Gothic-10 


10 


48 




PN 


Gothic-10 


10 


60 




QN 


Gothic-10 


10 


60 




QNC 


Gothic-10 


10 


60 




RN 


Gothic-10 


10 


52 




XN 


Gothic-10 


10 


40 




YN 


Gothic-10 


10 


42 




SN"* 


Text 1 & 2 


10 


84 




tn'^ 


Text 1 & 2 


10 


120 


OCR 


aoa'^ 


Gothic-10, OCR-A 


10 


48 


group 


aod'^ 


Gothic-10, OCR-A 


10 


48 




AON* 


Gothic-10, OCR-A 


10 


48 




QAA* 


Gothic-10, OCR-A 


10 


48 




ODA* 


Gothic-10, OCR-A 


10 


48 




ON A* 


Gothic-10, OCR-A 


10 


48 




BOA* 


Gothic-10, OCR-A 


10 


48 




BON* 


Gothic-10, OCR-B 


10 


48 




OAB 


OCR-B 


10 


48 




ONB* 


Gothic-10, OCR-B 


10 


48 


Katakana 


2773* 


Gothic-10, Katakana-10 


10 


62 


group 


2774* 


Gothic-10, Katakana-10 


10 


108 




KN1* 


Gothic-10, Katakana-10 


10 


127 


Format 


FM10 


Format-10 


10 


36 


group 


FM12 


Format-12 


12 


36 




FM15 


Format-15 


15 


36 


^ For any tab 


6 using 10-pitch Gothic or Katakana, the pitch can be cha 


nged to 1 2 


or 1 5 by 


changing thi 


: character set identifier using the iEBIMAGE utility. 






^Not includir 


ig a blank, which is also part of each character set except H 


Catakana. 




^TheGFIOJ 


jF12, GF15, and GFC tables provide the folding effect to 


allow the 


printing 


of uppercasf 


5 graphic characters when lowercase are called for. 






*This characi 


er arrangement table uses two WCGMs. 







Figure 28 A. Character Arrangement Tables Supplied with the 3800 
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The JOB Statement 



//Nc 



//jobr 



Operation 



JOB 



Operand 



([account- numberj [, additional accounting information,...]) 

VIRT i\ 
REAL /J 



ADDRSPC = -{f:^—^' 








',0" 




2 




, 1 


) 



[CLASS=iobclass] 

[CO ND=((code, operator), . . .)] 

[MSGCLASS=output class] 

MSGLEVEL=( 

[NOTIFY=user identification] 

[PERFORM=n] 

[programmer's name] 

[PRTY=priority] 



RD=lRNC( 
NC 
NR 



[REGION=valueK] 



RESTARTS 



stepname ( [,checkid]) 

stepname .procstepname | 



rTIME=f([min 
[_ \ 144 



utes] [, seconds])! 
1440 i 



rTYPRUN=(HOLD) 



<SCAN> 

icopy)" 



Legend: 

P Positional parameter. 

K Keyword parameter 

I f Choose one . 

[] Optional; if more than one line is enclosed, choose one or none. 



P/K 



Comments 



Identifies accounting information. 
Can be made mandatory. 

Requests storage type. 



Assigns a job class to each job. 



Specifies test for a return code. 



Assigns an output class for the Job. 



Specifies what job output is to be 
written. 



Requests a message be sent to a 
time-shoring terminal. 



Specifies the performance group a 
job belongs to. 



Identifies programmer. 
Can be made mandatory. 



K In JES3, specifies a job's initiation 
I priority within Its job class. 



Specifies restart facilities to be used. 



Specifies amount of storage space. 



Specifies restart facilities for 
deferred restart. 



Assigns a job a CPU time limit. 



Holds a job In job queue, scans 
JCL for syntax errors, or copies 
the Input deck to SYS OUT. 



i 



Figure 29. The JOB Statement 



i 



318 OS/VS2 JCL (VS2.03.810) 



The EXEC Statement 


//Name 


Operation 


Operand 


P/K 


Comments 


// [stepname] 


EXEC 


[ACCT [.procstepname] = (accounting information, . . .)] 


K 


Accounting information 
for step . 






CAP»sPc.{m}] 


K 


Requests storage type . 






(code, opera tor) 
[COND [.procstepname] = ( (code, operator, stepname) 

(code, opera tor, stepname. procstepname) 




K 


Specifies a test for a 
return code. 






' • • • f'l 


'EVEN ' 


)] 










L J 


ONLY 












[DPRTY [.procstepname]=([vafueT] [,value2])] 


K 


Specifies dispatching 
priority for a job step. 






[DYNAMNBR [.procstepname] =n] 


K 


Specifies dynamic 
allocation. 






[PARM [.procstepname] =value] 


K 


Passes variable informa- 
tion to a program at 
execution time. 






[PERFORM [.procstepname] =n] 


K 


Specifies a performance 
group for a job. 






program name 
[PGM= *. stepname. ddname ] 


P 


Identifies program. 






* . stepname .procstepname . ddname 










[ [PROC=3 procedure name] 


*P 


Identifies a cataloged 
or instream procedure. 






JR j 

[RD [.procstepname] = JRNCJ ] 
NC 


K 


Specifies restart facili- 
ties to be used. 






(nr I 










[REGION=valueK] 


K 


Specifies amount of 
storage space. 






[time [.procstepname] = /([minutes^ [, seconds] ) I] 
I 1440 ) 


K 


Assigns step CPU time 
limit. 


Legend: 




K Keyword parameter. 




P Positional parameter. 
1 ( Choose one . 




[3 Optional; if more than one line is enclosed, choose one or none. 








Figure 30. The EXEC Statement 
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The DD Statement 



//Nc 



Oper- 
ation 



Operand 



P/K 



Comments 



// 



ddname 
procstepname, 
ddname 



DD 



[* ] 



AMP= 



/AMORG 
,'BUFND=number' 
,'BUFNI=number' 
,'BUFSP=number' 
, 'CROPS= ( RCK' 
INCK' 
)NRE' 

(nrc 

,'OPTCD= ( I' 
L' 
IL 

,'RECFM= 



l^^' 



I^VB'j 
,'STRNO=number' 
, 'SYNAD=modulename' 
, TRACE 



[^URST={y] 



[CHARS=(table name [, table name ...])] 

[CHKPT=EOV] 

[COPIES=(nnn[, (group value, group value . . .)])] 

[data] 

DCB={iist of ottributes) 

Sdsname 
*. ddname 
* . stepnam e . dd nam e 
*.stepname. procstepname. ddname 

[DDNAME=ddname] 
[DEST=desti nation] 



■[,list of attributes] ) 



DISP=( 



NEW 
OLD 
SHR 
MOD 



, DELETE 

,KEEP 

,PASS 

,CATLG 

,UNCATLG 



,DELETE 
,KEEP 
,CATLG 
,UNCATLG 



LDLM=delimifer] 



Defines data set in the input 
stream . 

Completes the access methoc 
control block (ACB) for VSA 
data sets. 



Specifies whether or not 
paper output is to go to 
the Burster-Trimmer- 
Stacker of the 3800. 



Specifies character 
arrangement table(s) to 
be used when printing 
on the 3800. 



i 



For checkpoint at end of 
volume. 

Requests multiple copies (and 
grouping, for the 3800 only) 

of the output data set. 

Defines data set in the input 
stream , 

Completes the data control 
block (used for all data sets 
except VSAM). 



Postpones the definition of a 
data set. 

Specifies remote destination 
for output data set. 

Assigns o status, disposition, 
and conditional disposition 
to the data set. 



Assigns delimiter other than 



/* 



Figure 31. The DD Statement (Parti of 3) 



1 
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The DD Statement (con t) 



//Nc 



Oper- 
ation 



Operand 



P/K 



Comment-s 



// 



ddname 
procstepname, 
ddname 



[DSID=(!d[,V])] 



DSNAME) 
:DSN ) 



[dummy] 

[dynam] 
r 

FCB=(irnci9e-id 



dsname 

dsname(member name) 
dsname(generation number) 
I dsname(area name) 
&&dsname 

&&dsname(member name) 
&&dsname(area name) 
*. ddname 

. stepname . ddname 

. stepname . procstepname . ddname 



, ALIGN 
, VERIFY 



[FLASH=(overlay name [, count])] 



LABELKNata set seq # 



,SL 

,SUL 

,AL 

,AUL 

,NSL 

,NL 

,BLP 

,LTM 



, PASSWORD 
,NOPWREAD 



L'OutJ 



['] 



■EXPDT=yyddd 
RETPD=nnnn 



[MODIFY=(module name[,trc])] 

[MSVGP=id] 
[OUTLIM=number] 



Indicates to a diskette reader 
that data is to be merged into 
the JCL stream at this point or 
specifies the name to be given 
to a SYSOUT data set written 
on a diskette. 

Assigns a name to a new data 
set or to identify an existing 
data set. 



Bypasses I/O operations on a 
data set (BSAM and QSAM). 

Specifies dynamic allocation. 

Specifies forms control infor- 
mation. The FCB parameter is 
ignored if the data set is not 
written to a 3211 or 1403 
printer. 

Identifies the forms overlay 
to be used on the 3800. 

Specifies dynamic 
deallocation. 

Specifies whether output 
processing is to be deferred or 
processed normally. 

Supplies label information. 



Specifies a copy 
modification module that 
is to be loaded into the 
3800. 



identifies a moss storage group 
for a mass storage system (MS5) 
device. 

Limits the number of logical 
records you want included in 
the output data set. 



€ 



Figure 31. The DD Statement (Part 2 of 3) 
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The DD Statement (con't) 



I 



//Name 



Oper- 
ation 



Operand 



P/K 



Comments 



// 



ddname 
procstepname , 
ddname 



DD 



[QNAME=process name] 



TRK 



SPACE=rjCYL /, (primary quantity [", 

I ( blocklength ) [_, 

['] ['^LSE] 



secondary quantity 



,CONTIG 

,MXiG 

,ALX 



,directory 
, index 



[, ROUND]) 



' SPACE=/ABSTR, (primary quantity, address ^directory] )\ 
^ ^ [/index J '' 



SYSOUT=(class name T, program namel (^form name 



Specifies the name of a 
TPROCESS macro which 
defines a destination queue 
for messages received by 
means of TCAM . 

Assigns space on a direct 
access volume for a new data 
set. 



r, program name"! f^form name 1 )| 
L, J (_,codenameJ J 



[TERM=TS] 



rUCS=(character set code |',F0LD"] [,VERIFY] ) 



rPOLDl [,VERIFY])1 



UNITK 



unit address 
device type 
user-assigned group name 



,unit count 
,P 



[, DEFER] ), 



UNIT=AFF=ddname 



|^°j-^'^^|=( [PRIVATE]!", retain! r, volume seq number] [, 



volume seq number] [, volume count]L,] 



SER=(serial number,...) 
REF=dsname 
REF=*. ddname 
REF=* . stepname .ddname 
_REF=*.stepname, procstepname. ddname J 



Assigns specific tracks on a 
direct access volume for a 
new data set. 

Assigns an output class to an 
otitput data set. 

Identifies a time-sharing user. 



Requests a special character 
set for a 3211 or a 1403 
printer. 

Provides the system with unit 
Information, 



Provides the system with 
volume information. 



i 



Legend : 

P Positional parameter. 
K Keyword parameter, 
j f Choose one. 



[] Enclosing subparameter, indicates that subparameter is optional; if more than one line is enclosed, 
choose one or more. 



Figure 31. The DD Statement (Part 3 of 3) 
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Glossary 



The following terms are defined as they are used in 
this manual. If you do not fmd the term you are 
looking for, refer to the Index or to the IBM Data 
Processing Glossary, GC20-1699. 

IBM is grateful to the American National 
Standards Institute (ANSI) for permission to 
reprint its definitions from the American National 
Standard Vocabulary for Information Processing 
(Copyright © 1970 by American National 
Standards Institute, Incorporated), which was 
prepared by Subcommittee X3K5 on Terminology 
and Glossary of American National Standards 
Committee X3. ANSI definitions are marked with 
an *. 

address space. The virtual storage assigned to a job, 
TSO user, or a task initiated by the START command. 
Each address space consists of the same range of 
addresses. 

affinity. (See volume affinity, unit affinity.) 

allocate. To assign a resource for use in performing a 
specific task. 

ASP. Asymmetric multiprocessing system that provides 
supplimentary support for job management, data 
management, and task management, performing such 
functions as scheduling input readers and output writers. 
ASP main processor. The MVT or SVM processor 
that executes jobs assigned to it by a JES3 global 
processor. 

associated data set. Data set on a 3540 diskette volume 
that is separate from the job stream data set and is to be 
spooled as a SYSIN data set. 

automatic priority group (APG). In VS2, a group of 
tasks at a single priority level that are dispatched 
according to a special algorithm that attempts to provide 
optimum use of CPU and I/O resources by these tasks. 

automatic restart. A restart that takes place during the 
current run, that is, without resubmitting a job; an 
automatic restart can occur within a step or at the 
beginning of a step. Contrast with deferred restart. 

auxiliary storage. Data storage other than main storage; 
secondary storage. 

backward reference. A facility of the job control 
language that permits you to copy information from or 
refer to DD statements that appear earlier in the job. 

card image form. Column binary. 

catalog. The collection of all data set indexes that are 
used by the control program to locate a volume 
containing a specific data set. 

catalt^ed data set. A data set that is represented in an 
index or hierarchy of indexes in the system catalog; the 
indexes provide the means for locating the data set. 

catalc^ed procedure. A set of job control statements 
that has been placed in a partitioned data set called the 
procedure library and that can be retrieved by coding 
the name of the procedure on an execute (EXEC) 
statement or started by a START command. 



checkpoint data set. A sequential or partitioned data set 
containing a collection of records (called checkpoint 
entries) that contain the status of a job and the system 
at the time the records are written. These records 
provide the information necessary for restarting a job 
without having to return to the beginning of the job. 

checkpoint restart. The process of resuming a job at a 
checkpoint within the job step that was abnormally 
terminated. The restart can be automatic or deferred, 
where deferred restart involves resubmitting the job. 
Contrast with step restart. 

checkpoint/restart facility. A facility for restarting 
execution of a program at some point other than at the 
beginning, after the program was terminated due to a 
program or system failure. A restart can begin at a 
checkpoint within a job step or at the beginnitig of a job 
step. 

command statement. A job control statement, JES2 
control statement, and JES3 control statement that is 
used to issue commands to the system through the input 
stream. 

comment statement. A job control statement used to 
include information that may be helpful in running a job 
or reviewing an output listing. 

concatenated data sets. A group of logically connected 
data sets that are treated as one data set for the duration 
of a job step. 

converter/interpreter. The job segment that converts 
and interprets JCL for the MVS system. 

cylinder. The tracks of a disk storage device that can be 
accessed without repositioning the access mechanism. 

data deflnition (DD) statement. A job control 
statement that describes a data set associated with a 
particular job step. 

data management. A major function of the operating 
system that involves organizing, cataloging, locating, 
storing, retrieving, and maintaining data. 

data set. The major unit of data storage and retrieval in 
the operating system, consisting of a collection of data in 
one of several prescribed arrangements and described by 
control information to which the system has access. 

ddname (data definition name). A name assigned to a 
DD statement. This name corresponds to the ddname 
appearing in a data control block. 

deadline scheduling. An automatic method of controlling 
a job's scheduling priority to increase the probability of 
the job being scheduled by a given deadline. 

deferred restart. A restart performed by the system on 
resubmission of a job by the programmer; deferred 
restart can begin within a step or at the beginning of a 
step. Contrast with automatic restart. 

delimiter statement. A job control statement used to 
mark the end of data. 

dependent job control (DJC). In JES3, the organizing 
of a collection of jobs that must execute in a specific 
order. DJC manages jobs that are dependent upon one 
another. 

device type. A number that corresponds to a type of 
input/output device. Coding the device type in the UNIT 
parameter is one way of indicating what input/output 
device you want allocated to a job step. 
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directory. A series of 256-byte records at the beginning of 

a partitioned data set that contains an entry for each 

member in the data set. 
dispatching priority. A number assigned to tasks, used to 

determine the order in which they will use the central 

processing unit. 
disposition processing. A function performed by the 

initiator at the end of a job step to keep, delete, catalog, 

or uncatalog data sets, or pass them to a subsequent job 

step, depending on the data set status or the disposition 

specified in the DISP parameter of the DD statement. 
dummy data set. A data set for which operations such as 

disposition processing, input/output operations, and 

allocation are bypassed. 
*dump. (1) to copy the contents of all or part of storage, 

usually from an internal storage into an external storage. 

(2) the data resulting from the process as in (1). 
dynamic aUocation. Assignment of system resources to a 

program at the time the program is executed rather than 

at the time it is loaded into main storage. 
dynamic deallocation. Freeing of system resources 

during program execution rather than at the end of the 

job. 
dynamic support jn-ogram (DSP). Transient program 

of JES3 that runs in parallel with the other support 

functions of JES3. 
execute (EXEC) statement. A job control statement 

that marks the beginning of a job step and identifies the 

program to be executed or the cataloged or in-stream 

procedure to be used. 
execution priority. A rank assigned to a task that 

determines its precedence in being selected for 

execution. 
external page storage. The portion of auxiliary storage 

that is used to contain pages. 
external writer. A writer other than JES2 for 

user-written writer routines and for devices not 

supported by JES2 or JES3. 
folding. A technique used with the universal character set 

(UCS) feature on an impact printer to allow each of the 

256 possible character codes to print some character on 

a chain or train with fewer graphics. For example, it 

allows the printing of uppercase graphic characters when 

lowercase are not available in the character array on the 

chain or train. 
forms control buffer (FCB). A buffer that is used to 

store vertical formatting information for printing, each 

position corresponding to a line on the form. 
generation data group (GDG). A collection of data sets 

that are kept in chronological order; each data set is 

called a generation data set. 
generation data set. One generation of a generation 

data group. 
global processor. JESS processor that controls the job 

selection for all processors in the system running under 

JES3. 
group name. See user-assigned group name. 
HASP. The HASP system provides supplimentary support 

for job management, data management, and task 

management, performing functions such as scheduling 

input readers and output writers. 



input service. In JES3 a set of dynamic support programs 

that read the input data and build the system input data 

set and control table entries for each job. 
input stream. The sequence of control statements and 

data submitted to the operating system on an input 

device especially activated for this purpose by the 

operator. 
in-stream procedure. A set of job control statements 

placed in the input stream that can be used any number 

of times during a job by naming the procedure on an 

execute (EXEC) statement. 
integrity. Preservation of data or programs for their 

intended purpose. 
JES2 control statement. A statement that controls the 

input and output processing of jobs run under JES2. 
JES3 control statement. A statement that controls the 

input and output processing of jobs run under JES3. 
job. A collection of related problem programs, identified 

in the input stream by a JOB statement followed by one 

or more EXEC and DD statements. 
job class. Any one of a number of job categories that can 

be defined by the installation to classify jobs. By 

classifying jobs and directing initiators to initiate specific 

classes of jobs, it is possible to control the mixture of 

jobs that are performed concurrently. 
job class queue. A waiting list of job definitions within 

the input queue in which jobs assigned the same class 

are arranged in order of priority; jobs with the same 

class and priority are placed in a first in/first out order. 
job control language (JCL). A high-level programming 

language used to code job control statements. 
*job control statement. A statement in a job that is 

used in identifying the job or describing its requirements 

to the operating system. 
job journal. Established at JES2 or JES3 initialization to 

hold restart information for each program in execution. 
job library. See private library. 
job management. A general term that collectively 

describes the functions of the job scheduler and master 

scheduler. 
job related output. Output that is neither held nor spun 

off nor processed by a user-written writer. 
job (JOB) statement. The job control statement that 

identifies the beginning of a job. It contains such 

information as the name of the job, an account number, 

and the class and priority assigned to the job. 
job step. A unit of work associated with one processing 

program or one cataloged procedure and related data. A 

job consists of one or more job steps. 
job step tas^. A task that is initiated by an initiator 

according to specifications in an execute (EXEC) 

statement. 
jobname. The name assigned to a JOB statement; it 

identifies the job to the system. 
K. 1024 bytes. 
keyword. A symbol that identifies a parameter or 

subparameter. 
keyword parameter. A parameter that consists of a 

keyword, followed by one or more values. 
local devices. Devices attached to the global processor at 

the central computer center for sending input and 

receiving output. 
local processor. The JES3 (MVS) processor that executes 

the jobs assigned to it by the global processor. 
local station. A station whose control unit is connected 

directly to a computer I/O channel. Contrast with 

remote station. 
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logical record. A record that is defined in terms of the 
information it contains rather than by its physical traits. 
You may have to specify the length of the logical record 
to complete the data control block; one way to specify 
this is in the LRECL subparameter of the DCB 
parameter. 

l(^cal region. The amount of real storage required by a 
job a job step to execute efficiently on an ASP main 
processor when running under JES3. 

loosely-coupled multiprocessing, two or more 
computing systems interconnected by an I/O 
channel-to-channel adapter. The CPUs can be of 
different types and have their own unique 
configurations. 

main service. In JES3, a dynamic support program 
schedules problem programs for execution and manages 
the flow of data (system input, print, and punch) across 
the channel-to-channel adapter to and from the global 
processor. 

Mass storage system ^oup (MSVGP). a named 

collection of mass storage volumes defined by the person 
in charge of controlling space. Both active and inactive 
mass storage volumes can be in the group. The volume 
group is identified by name in JCL on the MSVGP 
parameter. 

mutually exclusive parameters. Parameters that cannot 
be coded on the same job control statement. 

MVS (multiple virtual storage). VS2 Release 2 and all 
subsequent VS2 releases. 

nonpageable dynamic area. An area of virtual storage 
whose virtual addresses are identical to real addresses; it 
is used for programs or parts of programs that are not to 
be paged during execution. 

nonsharable volume. A volume that cannot be assigned 
to two or more data sets. 

nonspecific volume request. A request that allows the 
system to select suitable volumes. 

nontemporary data set. A data set that exists after the 
job that created it terminates. 

null statement. A job control statement used to mark the 
end of a job's control statements and data. 

♦operating system (OS). Software which controls the 
execution of computer programs and which may provide 
scheduling, debugging, input/output control, accounting, 
compilation, storage assignment, data management, and 
release services. 

output class. Any one of up to 36 different categores, 
defined at an installation, to which output data produced 
during a job step can be assigned. When an output 
writer is started, it can be directed to process from one 
to eight different classes of output data. 

♦output data. (SCl) Data to be delivered from a device 
or program, usually after some processing. 

output listing. A form that is printed at the end of a job 
that can contain such information as job control 
statements used by the job, diagnostic messages about 
the job, data sets created by the job, or a dump. 

output service. A JES3 service that prints and punches 
the data sets created during main service. 

page. A fixed-length block of instructions, data, or both, 
that can be transferred between real storage and external 
page storage. 

partitioned data set. A data set in direct access storage 
that is divided into partitions, called members, each of 
which can contain a program or part of a program. Each 
partitioned data set contains a directory (or index) that 



the control program can use to locate a program in the 
library. 

passed data set. A data set allocated to a job step that is 
not deallocated at step termination but that remains 
available to a subsequent step of the same job. 

PEND statement. A job control statement used to mark 
the end of an in-stream procedure. 

permanently resident volume. A volume that cannot be 
physically demounted or that cannot be mounted until it 
is varied offline (that is, removed from the control of the 
central processing unit). 

physical record. A record that is defined in terms of 
physical quaUties rather than by the information it 
contains (logical record). 

positional parameter. A parameter that must appear in a 
specified order. 

priority. A value assigned to a job that is used to 
determine when a job is selected for execution. 

private library. A user-owned library that is separate and 
distinct from the system library. 

private volume. A mounted volume that the system can 
allocate only to a data set for which a specific volume 
request is made. 

PROC statement. A job control statement that must 
mark the beginning of an in-stream procedure; it can 
also be used, in both cataloged and in-stream 
procedures, to assign values to symbolic parameters in 
the procedure. 

procedure library. A partitioned data set containing 
cataloged procedures; the IBM-supplied procedure 
library is named SYSl.PROCLIB. 

procedure step. That unit of work associated with one 
processing program and related data within a cataloged 
or in-stream procedure. A cataloged or in-stream 
procedure consists of one or more procedure steps. 

public volume. The term applied to a mounted volume 
that the system can allocate to an output data set for 
which a nonspecific volume request is made. A public 
volume remains mounted until the device on which it is 
mounted is required by another volume. 

qualified name. A data set name that is composed of 
multiple names separated by periods (for example, 
A.B.C.). For a cataloged data set, each name 
corresponds to an index level in the catalog. 

queue. A waiting line or list formed by items in a system 
waiting for service; for example, tasks to be performed 
or output to be written by a writer. 

reader/interpreter. The job segment that reads and 
interprets JCL for jobs on ASP main processors. 

real storage. The storage of a system/370 computing 
system from which the central processing unit can 
directly obtain instructions and data, and to which it can 
directly return results. 

recwd. A general term for any unit of data that is distinct 
from all others. 

region. In systems with MVS, a subdivision of the 

dynamic area of main storage set aside for a job step or 
a system task. You can specify in the REGION 
parameter on the JOB statement or EXEC statement 
how large this area of main storage should be. 

remote devices. Devices attached to remote work 
stations for sending input and receiving output. 

remote job entry. Submission of job control statements 
and data from a remote terminal, causing the jobs 
described to be scheduled and executed as though 
encountered in the input stream. Also known as remote 
job processing in JES3. 
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remote job processing (RJP). The processing of jobs 
submitted from remote terminals. 

remote station. (1) * Data terminal equipment for 
communicating with a data processing system from a 
location that is time, space, or electrically distant. (2) 
Contrast with local station. 

reserved volune. A volume that remains mounted until 
the operator issues an UNLOAD or VARY OFFLINE 
command. 

resource. Any facility of the computer system or 

operating system required by job or task and includes 
main storage, input/output devices, the CPU, data sets, 
and control and processing programs. 

restart. The process of resuming a job after it abnormally 
terminates. When a restart is performed, processing is 
continued either at the beginning of a job step that 
caused the abnormal termination or at a checkpoint 
within this job step. 

restart facility. See checkpoint/restart facility. 

return code. A value placed in the return code register at 
the completion of a program. The value is established by 
the user and may be used to influence the execution of 
succeeding programs or, in the Case of an abnormal end 
of task, may simply be printed for programmer analysis. 
scheduling priority, a rank assigned to a task that 
determines its precedence in being scheduled. 

sequential data set. A data set whose records are 
organized on the basis of their successive physical 
positions, such as they are on magnetic tape. 

specific volume request. A request for volumes that 
informs the system of the volume serial numbers. 

spooled data set. A data set written on an auxiliary 
storage device. 

standard job. a JES3 job that consists of input service 
main service, output service, and purge performed in 
that order. 

step restart. A restart at the beginning of a job step that 
abnormally terminates. The restart may be automatic 
(depending on an eligible completion code and the 
operator's consent) or deferred, where deferred involves 
resubmitting the job and coding the RESTART 
parameter on the JOB statement of the resubmitted job. 

stepname. The name assigned to an EXEC statement; it 
identifies a job step within a job. 

storage volume. The main function of a storage volume 
is to contain nontemporary data sets for which a 
nonspecific volume request was made and PRIVATE 
was not coded in the VOLUME parameter. A direct 
access volume becomes a storage volume when so 
indicated in a MOUNT command or in a member of 
SYSl.PARMLIB named VATLSTxx. 

symbolic parameter. A symbol preceded by an 
ampersand that stands for a parameter or the value 
assigned to a parameter or subparameter in a cataloged 
or in-stream procedure. Values are assigned to symbolic 
parameters when the procedure in which they appear is 
called. 

system generation. The process of using an operating 
system to assemble and link together all of the parts that 
constitute another operating system. 

S}^tem library. A partitioned data set named 

SYSl.LINKLIB that contains programs used by the 
system. 

system messages. Messages issued by the system that 
pertain to a problem program. These messages appear 
on an output listing and may include such messages as 



error messages, disposition messages, and 

allocation/deallocation messages. 
system output device. A device assigned to record 

output data for a series of jobs. 
system resources manager. A group of programs that 

controls the use of system resources in order to satisfy 

the installation's performance objectives. 
SYS.LINKLIB data set. See system library. 
SYS1.PROCLIB data set. See procedure library. 
table reference character. A numeric character (0,1,2, 

or 3) corresponding to the order in which the character 

arrangement table names have been specified with the 

CHARS keyword. 
task. A unit of work for the central processing unit from 

the standpoint of the control program; therefore, the 

basic multiprogramming unit under the control program. 
temporary data set. A data set that is created and 

deleted in the same job. 
temporary library. A library that is created and deleted 

within a job. 
*track. The portion of a moving storage medium, such as 

drum, tape, or disk, that is accessible to a given reading 

head position. 
unit. A particular device specified by its unit address, 

device type, or user-assigned group name. 
unit address. The three-character address of a particular 

device, specified at the time a system is installed; for 

example, 191 or 293. 
unit afHnity. A condition under which two or more 

volumes are located on the same device. 
universal character set (UCS) feature. A printer 

feature that permits the use of a variety of character 

arrays. 
user-assigned group name. Installation defined name to 

signify a group of devices that may or may not all be of 

the same type (specified through JCL in the UNIT 

parameter). 
virtual input/output (VIO). Facility to handle 

temporary data sets that causes them to reside within the 

paging data sets. To problem program or access method, 

the data sets appear to reside on some other real direct 

access storage device. 
virtual Stor^e. Addressable space that appears to the 

user as real storage, from which instructions and data 

are mapped into real storage locations. The size of 

virtual storage is limited by the addressing scheme of the 

computing system and by the amount of auxiliary 

storage available, rather than by the actual number of 

real storage locations. 
volume. That portion of an auxiliary storage device that is 

accessible to a single read/write mechanism. 
volume affinity. A condition under which two or more 

data sets are located on the same volume. 
volume taWe of contents (VTOC). A table on a direct 

access volume that describes each data set on the 

volume. 
work station. A terminal device that may or may not be 

a CPU. At a workstation, an operator can connect into a 

central system via LOGON, enter jobs, and receive 

output. 
working set. The estimate of bytes of real storage used 

by the steps of a job. 
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Index 



b use !29 
{} braces, use 129 
n brackets, use 129-130 
... use 130 

++ (instream procedure) 123 
++* (instream procedure) 123 
+// (instream procedure) 123 
& use 124 

& & identifying temporary data set 45 
$A 264 
$B 264 
$C 264 
$D 264 
$E 264 
$F 264 
$H 264 
$1 264 
$L 264 
$N 264 
$P 264 
$0 264 
$R 264 
. $S 264 
$T 264 
$VS 264 
$Z 264 

* parameter on DD statement 189-190 

creating a data set 189 

data in input stream 189-190 

description 101 

restriction for cataloged or in-stream procedure 

retrieving a data set 310 

separating groups of data 190 

(see also DATA and DLM parameters) 

* in PGM parameter 166-167 

* in PRIORITY statement 270 

* subparameter in RESTART parameter 150-151 
*** comment statement 123 

♦.ddname 

in the DCB parameter 198 

in the DSNAME parameter 219 
♦.stepname. ddname 

in the DCB parameter 198 

in the DSNAME parameter 219 

in the PGM parameter 166-167 
♦.stepname.procstepname. ddname 

in the DCB parameter 198 

in the DSNAME parameter 219 

in the PGM parameter 166-167 
/* delimiter 255 
/* for JES2 control statements 263 



ABEND dumps 

(see abnormal termination dump) 
ABNORMAL parameter on NET statement (JES3) 

description . 300 

use of 77-81 
abnormal termination dump 

JES2 63 

JES3 87-88 
absolute track technique 

for ISAM data set 108 
ABSTR subparameter of SPACE Parameter 

assigning specific tracks 39 

description 236,237 

for ISAM data sets 108 



AC parameter on FORMAT statement (JES3) 

283-285,282 
accessing TCAM messages 235 

I accounting information parameter on JOB statement 136 
JES2 parameters for 136 (VS2.03.803) 
ACCT parameter on EXEC statement 156 
ACHOLD parameter on MAIN statement (JES3) 

292,296,298 
ACMAIN parameter on MAIN statement (JES3) 

292,296,298 
address space 323 
address subparameter of SPACE parameter 

assigning specific tracks 39 

description 236-237 
address, unit 

on UNIT parameter 244 

specifying unit information 31 
ADDRSPC parameter 

on EXEC statement 157-158 

on JOB statement 137 

requesting storage 27-28 
AFF subparameter of UNIT parameter 

description 244,246 

requesting unit affinity 33-35 
affinity 323 

unit (see unit affinity) 

volum.e (see volume affinity) 
AL subparameter of LABEL parameter 

(American National standard labels) 229 
ALIGN subparameter of FCB parameter 225 
17 alignment of forms 67 

allocating devices (JES3) 72-75 

(see also SETUP parameter on MAIN statement) 
allocation 

absolute track 108 

definition 323 

devices eligible 29 

dynamic (see DYNAM parameter on DD statement and 
DYNAMNBR parameter on EXEC statement) 

nonspecific 108 

(see also SPACE parameter on DD statement) 
allocation/termination messages 

(see system messages) 
alphameric character sets 67,91 
ALX subparameter of SPACE parameter 236,238 
American National standard labels 229 
AMORG subparameter of AMP parameter 191 
AMP parameter on DD statement 

defines VSAM data set 102-105 

description 191-193 
ampersand 

as special character 129 

identifying symbolic parameter 124 

identifying temporary data set 44 
AN character set (1403) 67,91 
ANSI printer control characters in 

RECFM subparameter 207-208 
ANSI tape labels 229 
APG (automatic priority group) 58,76-77 
apostrophe, specifying 46 
ASCII magnetic tape 

(see DCB parameter) 

(see LABEL parameter) 
ASP 323 
ASP main processor 

definition 323 

how to specify 72 
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restarting a job 85 

TSO on (see FORMAT AC and MAIN statements 
(JES3)) 
associated data sets 45-46,323 

(see also DSID parameter on DD statement) 
attributes, DCB 

(see DCB subparameters) 
AUL subparameter of LABEL parameter 

(American National standard and user labels) 229 
automatic priority group 58,76-77,323 

(see also priority) 
automatic restart 

definition 323 

use of (JES2) 62 

use of (JES3) 85 

(see also RD parameter) 
automatic step restart (JES2) 62 
automatic step restart (JES3) 85 
aiixiliary storage 323 
average block length, space request 

(see block length subparameter) 
All character set (3211) 67,91 



backward reference 

copying a data set name 46 

DDNAME parameter 210 

definition 323 

DUMMY parameter 222 

generation data group 1 13-1 14 

VOLUME parameter 247,249 
basic direct access method 

(see BDAM subparameters of DCB parameter) 
basic indexed sequential access method 

(see BISAM subparameters of DCB parameter) 
basic partitioned access method 

(see BPAM subparameters of DCB parameter) 
basic sequential access method (BSAM) 

(see BSAM subparameters of DCB parameter) 
basic telecommunications access method 

• (see BTAM subparameters of DCB parameter) 
BDAM subparameters of DCB parameter 201-209 
BFALN subparameter of DCB parameter 201 
BFTEK subparameter of DCB parameter 201 
BISAM subparameters of DCB parameter 201-209 
blank 131 
BLKSIZE subparameter of DCB parameter 

coded with 

* parameter 189 
DATA parameter 196 
bpNAME parameter 210 

description 201 
blocklength subparameter of SPACE parameter 

description 236,237 

requesting space 37 
blocks, directory, for BPAM 

(see directory) 
blocksize (see BLKSIZE subparameter of DCB parameter) 
BLP subparameter of LABEL parameter 229,230 
BPAM subparameters of DCB parameter 201-209 
braces {} 129 
brackets [] 129-130 
buffers 

boundary (see BFALN subparameter) 

length of (see BUFL subparameter) 

number of (see BUFNO subparameter) 

for all lines (see BUFSIZE subparameter) 

for one line (see BUFMAX subparameter) 

for receiving operation (see BUFIN subparameter) 

for sending operation (see BUFOUT subparameter) 

offset (see BUFOFF subparameter) 



type (see BFTEK subparameter) 
BSAM subparameters of DCB parameter 201-209 
BTAM subparameters of DCB parameter 201-209 
BUFIN subparameter of DCB parameter 201 
BUFL subparameter of DCB parameter 201 
BUFMAX subparameter of DCB parameter 201 
BUFND suparameter of AMP parameter 191,193 
BUFNI subparameter of AMP parameter 191,193 
BUFNO subparameter of DCB parameter 

coded with 

♦parameter 189 
DATA parameter 196 
DDNAME parameter 210 

description 201 
BUFOFF subparameter of DCB parameter 201 
BUFOUT subparameter of DCB parameter 201 
BUFSIZE subparameter of DCB parameter 201 
BUFSP subparameter of AMP parameter 191,193 
BURST parameter 

bursting of output (JES2) 68.1 (VS2.03.8I0) 

bursting of output (JES3) 92 (VS2.03.810) 

on DD statement 193.0 (VS2.03.810) 

on OUTPUT statement (JES2) 268 (VS2.03.803) 
bypassing data set allocation 

defining a dummy data set 98-99 
bypassing disposition processing 54 
bypassing job initiation (JES2) 60 
bypassing label processing 229,230 
bypassing I/O operations 

(see DUMMY parameter on DD statement) 
bypassing job steps 

(see COND parameter on EXEC statement) 



CALL operator command (JES3) 276 
CANCEL operator command 

forJCL 251 

for JES3 276 
capacities of devices 
card forms (JES3) 

(see FORMS parameter on FORMAT PU statement) 
card image form 323 
CARDS parameter 

on JOBPARM statement (JES2) 265 

on MAIN statement (JES3) 292,293,297 
CARRIAGE parameter on FORMAT PR statement (JES3) 

287,288,289 
carriage tape (JES3) 

(see CARRIAGE parameter on FORMAT PR statement) 
catalog 323 
cataloged and in-stream procedures 

calling 117,163 

changes, allowing for 1 18 

DD statements, modifying 121-122 

definition of 117 

EXEC statements, modifying 119-121 

identifying (in-stream procedure) 117 

introduction 23-24 

modifying 1 19 

passing information (JES2) 59 

passing information (JES3) 83 

procedure library 118 

procedure statement identifying 123 

restriction on contents of 117 

symbolic parameter 123-128 

using 119-123 

writing 117-118 
cataloged data set 323 
cataloged procedure 

adding to procedure library 118 

calling 119,163 
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DD statements 121-122,176 

definition 23-24,323 

description of 117 

example of 128 

JOBLIB statement 178-179 

selecting a catalog procedure library 60 

symbolic parameters 123-128 

TIME parameter 172 
cataloging a data set 

(see CATLG subparameter of DISP parameter) 
CATLG subparameter of DISP parameter 

description 214,215 

use of 51-54 
changing a user's password 142.1 (VS2.03.804) 
channel program, active 

requesting real storage 27 
character arrangement tables 

supplied with 3800 317.0 (VS2.03.810) 

used with MODIFY 231.0 (VS2.03.810) 

(see also CHARS parameter) 
character control 

forJES2 67-68 (VS2.03.810) 

for JES3 90. 1-92 (VS2.03.810) 
character set codes 

for JES2 67 

for JES3 91 
character set, requesting 

universal (UCS) 67,91 

examples 243 

description 133-134 
CHARS parameter 

on DD statement 193.1 (VS2.03.810) 

on FORMAT PR statement (JES3) 287,288,289 
(VS2.03.810) 
I on OUTPUT statement (JES2) 268 (VS2.03.803) 

use of (JES2) 68 (VS2.03.810) 

use of (JES3) 91-91.0 (VS2.03.810) 
checkpoint for jobs on ASP main processors 85 
checkpoint data set 323 

(see also SYSCHK DD statement) 
checkpoint restart 

definition 323 

job step checkpoint option (see JOBSTEP parameter on 
MAIN statement (JES3) 

for generation data group 1 14 

use of (JES2) 61-62 

use of (JES3) 84-85 

(see also RD parameter and SYSCHK DD statement) 
checkpoint/restart facility 323 

(see also SYSCHK DD statement, RESTART parameter 
on JOB statement, and RD parameter) 
CHKPT macro instruction 

RD parameter 146,169 

use of (JES2) 61 

use of (JES3) 84 
CHKPT parameter on DD statement 

description 194 

use of 61,84 
CHNGDUMP operator command 251 
class (see CLASS parameter) 
CLASS parameter 

on JOB statement 138 

on MAIN statement (JES3) 292,294,297 

use of (JES2) 57-58 

use of (JES3) 75 
class name subparameter of SYSOUT parameter 239 
CLOSE subparameter of FREE parameter 

description 227 

dynamic allocation 41 
code name subparameter of SYSOUT parameter 239 
code parameter on OUTPUT statement 268 



CODE subparameter of DCB parameter 202 
comma 

continuing control statements 132 

leading and trailing commas, caution 126-128 

purpose 129,131 

when defining symbolic parameters 125 
command statement 

definition 323 

forJCL 251,21 

for JES2 264,22 

for JES3 276-277,23 
comment statement 

definition 323 

description 253 

introduction 21 
comments field 

continuing 132 
completion codes 139,159 
concatenated data sets 323 
concatenation 

data sets 122 

private libraries 97-98 

symbolic parameters 123-128 
concurrent use, data set 55 
COND parameter 

on EXEC statement 159-160 

on JOB statement 139 

use of (JES2) 61 

use of (JES3) 82 
conditional disposition of data set 51-53 

(see also DISP parameter on DD statement) 
conditional execution of job steps 

testing return codes (JES2) 61 

testing return codes (JES3) 82 

(see also COND parameter) 
CONTIG subparameter of SPACE parameter 

description 236,238 

use of 108 
contiguous space 

requesting 36-39 

for indexed sequential data sets 108 
continuing control statements 132 
control of nontemporary data set 

exclusive control 54 

shared control 55 
CONTROL parameter on FORMAT PR statement (JES3) 

287,288,289 
control printing (JES2) 

length of form and lines per inch 67-68 

special character sets 67 
control program (JES3) 72 

(see also TYPE parameter on MAIN statement) 
control statements 

continuing 1 32 
converter/interpreter 323 
COPIES parameter 

on FORMAT PR statement (JES3) 287,288,289 

on FORMAT PU statement (JES3) 290,291 

on JOBPARM statement (JES2) 265 

on OUTPUT statement (JES2) 268 

on SYSOUT DD statement 195 

requesting multiple copies (JES2) 66 

requesting multiple copies (JES3) 90 
copy input deck and bypass job initiation 60 
copy modification module (VS2.03.810) 

(see MODIFY parameter) 
COPY subparameter of TYPRUN parameter 153 

(see also bypassing job initiation) 
COPYG parameter on OUTPUT statement (JES2) 268 

(VS2.03.803) 
copying the data set name 46 
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count subparameter of FLASH parameter 

on DD statement 226.1 (VS2.03.810) 

on FORMAT PR statement (JES3) 287,288.1,289 
(VS2.03.810) 
CPU time limit 

on EXEC statement 172 

on JOB statement 152 
CROPS subparameter of AMP parameter 191 
CPRI subparameter of DCB parameter 202 
CYL (cylinders) subparameter of SPACE parameter 

description 236-237 

space request 36-39 
cylinders 

definition 323 

number per device 316 

(see also CYL subparameter of SPACE) 
CYLOFL subparameter of DCB parameter 202 



data 

identifying 27-56 

modifying 66.1,90 (VS2,03.8 10) 
data control block 

(see DCB parameter) 
data definition (DD) statement 323 

(see also DD statement) 
data management 323 
DATA parameter on DD statement 

creating a data set 308-309 

data in input stream 101,117 

description 196-197 

restrictions 196 

retrieving a data set 310 

separating groups of data 196 

(see also * and DLM parameter) 
data set, non-VSAM 

cataloging 52 

creating 308-309 

definition 323 

delaying writing of (JES2) 65 

delaying v^riting of (JES3) 89 

deleting 51-52 

disposition processing 50-56 

exclusive control of 54 

extending 311 

identifying to system 42-50 

integrity 54-55 

keeping 52 

multivolume 3 1 

nontemporary, creating 43-44 

nontemporary, retrieving 43-44 

passing 53 

parameters 42-43 

retrieving 310 

shared control of 55 

temporary, creating 44-45 

temporary, retrieving 44-45 

uncataloging 53 

writing output (JES2) 63-68 

writing output (JES3) 87-93 
data set disposition 

(see DISP parameter on DD statement) 
data set integrity 54-55 
data set label 

completing the data control block 198-199 

copying attributes from 199 

model 111-112 
data set name 

copying 46 

in apostrophes 46 

special characters, rules of 46,220 



temporary 220 

nontemporary 220 
data set organization 

(see DSORG subparameter of DCB parameter) 
data set sequence number subparameter on LABEL 

parameter 229-230,47 
data set status 

description 214 

use of 50-51 
DATASET statement for JES3 

description 278-279 

introduction 23 
DCB macro instruction 

coding the DCB parameter 198 

requesting exclusive control of part 
of a data set 54 
DCB parameter on DD statement 

for dummy data set 99 

definition 198-200 

description by access method 198-209 

indexed sequential data sets 106,107,110 

modifying in cataloged or instream 
procedures 119,121-122 

for private libraries 97 

BDAM subparameters 201-209 

BISAM subparameters 201-209 

BPAM subparameters 201-209 

BSAM subparameters 201-209 

BTAM subparameters 201-209 

EXCP subparameter 201-209 

GAM subparameters 201-209 

QISAM subparameter 201-209 

QSAM subparameters 201-209 

TCAM subparameters 201-209 
DD statement 

description 175-176 

data in input stream, restriction 117 

definition 320-322,323 

introduction 21-22 

special ddnames 175 
ddname 323 
DDNAME parameter 

on DATASET statement (JES3) 278 

oil DD statement 210-211,42 

on FORMAT AC statement (JES3) 283,284 

on FORMAT PR statement (JES3) 287,289 

on FORMAT PU statement (JES3) 290,291 
DEADLINE parameter on MAIN statement (JES3) 

292,295,298 
deadline scheduling (JES3) 

definition 323 

use of 75-76 

(see also DEADLINE parameter on MAIN statement) 
deallocation, dynamic 

(see FREE parameter on DD statement) 
dedicated devices 

dependent job control 77-78 

(see also DEVPOOL parameter on NET statement 
(JES3)) 
default disposition processing 53-54 
DEFER subparameter of UNIT parameter 

description 244,245 

use of 32 
deferred mounting 

(see DEFER subparameter of UNIT parameter) 
deferred restart 

definition 323 

use of (JES2) 62 

use of (JES3) 85 

(see also RD parameter on JOB and EXEC statements) 
DELAY operator command (JES3) 276 
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delaying job initiation (JES2) 60 

TYPRUN=HOLD parameter 153 

SETUP control statement (JES2) 273 
delaying the writing of an output data set (JES2) 65 
delaying the writing of an output data set (JES3) 89 
DELETE subparameter of DISP parameter 

description 214,215 

use of 51-52 
deleting a data set 

(see DELETE subparameter of DISP parameter) 
deleting records 

exclusive control 54 
deleting unused space 

(see RLSE subparameter of SPACE parameter) 
delimiter statement 

definition 323 

description 255 

input stream data 101 

introduction 21 

(see also DLM, DATA, and * parameters) 
delimiter other than /* 

(see DLM parameter on DD statement) 
demounting a tape volume 

(see VOLUME parameter on DD statement) 
DEN subparameter of DCB parameter 202 
dependent job control 

dedicating devices to 77-78 

definition 323 

dependencies between jobs in different nets 77-78 

exam.ples of 79-81 

how to code 78-79 

when used 77-78 

(see also NET statement (JES3)) 
DEST parameter 

on DD statement 212-213 

on FORMAT AC statement (JES3) 283,284 

on FORMAT NJP statement (JES3) 286 

on FORMAT PR statement (JES3) 287,289 

on FORMAT PU statement (JES3) 290,291 

on OUTPUT statement (JES2) 268,269 

output destination (JES2) 68 

output destination (JES3) 92 

(see also ROUTE statement (JES2)) 
destination (JES2) 

(see DEST parameter on DD and OUTPUT statements 
and ROUTE statement) 
destination (JES3) 

(see DEST parameter on DD and FORMAT statements) 
devices 

capacities 316 

for dependent job control 78 

JES3 setup 73-75 

specifying JES2 64 

valid for VSAM 103 
device type 

definition 323 

list of found in SPL: System Generation Reference 244 

subparameter of UNIT parameter 244,245 

use of 31 
DEVPOOL parameter on NET statement (JES3) 

description 300, 30 1 , 302 

use of 78 
DEVRELSE parameter on NET statement (JES3) 

description 300,301,302 

use of 78 
DIAGNS subparameter of DCB parameter 202 
dispatching priority 

assigning 58,76-77 

APG default 58,76-77 

execution priority (JES3) 77 
direct access capacities 316 



direct access data sets 

disposition processing 51,53 

shared control 55 
direct access device 29 
direct access volumes 

for partitioned data sets 38 

for passed data sets 53 
directory 

definition 38,324 

subparameter of SPACE parameter 236,238 
DISABLE operator command (JES3) 276 
DISP parameter on DD statement 

description 214-216 

disposition processing, non-VSAM 50-56 

for generation data set 1 12, 1 14 

for private library 96 

for ISAM data set 108,110 

on JOBLIB DD statement 178 

on STEPLIB DD statement 182,183 

on SYSABEND DD statement 185 

on^SYSCHK DD statement 187^188 

on SYSUDUMP DD statement 185 
dispatching priority 

assigning (JES2) 58 

assigning (JES3) 76-77 

definition 324 

use of APG (JES2) 58 

use of APG (JES3) 77 

(see also DPRTY parameter on EXEC statement) 
DISPLAY operator command 251 
disposition, non-VSAM data set 

bypassing 54 

conditional 53 

default 53-54 

processing of 50-56,315,324 

specifying 50-51 

unretrieved passed 53 
DLM parameter on DD statement 

description 217 

input stream data 101 

(see also DATA and * parameters and delimiter 
statement) 
DPRTY parameter on EXEC statement 

calculating dispatching priority (JES2) 56 

calculating dispatching priority (JES3) 76-77 

description 161 
DSID parameter on DD statement 

associated data sets 45-46 

creating a data set 308 

description 218 

retrieving a data set 310 
DSN parameter on DD statement 

(see DSNAME parameter) 
DSNAME parameter on DD statement 

adding members to a private library 96 

apostrophes, specifying 46 

description 219-221 

for generation data set 112,1 1 3,44 

for private library 96-97 

for ISAM data sets 106,109 

members of a partitioned data set 44 

nontemporary data set 220,43-44 

on JOBLIB DD statement 178-179 

on STEPLIB DD statement 182-183 

on SYSABEND DD statement 185 

on SYSCHK DD statement 187-188 

on SYSUDUMP DD statement 185 

special characters, specify 220 

specifying DSNAME 43 

storing a dump (JES2) 63 

storing a dump (JES3) 87-88 
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temporary data set 220,44-45 
DSNAME=NULLFILE 99 
DSORG subparameter of DCB parameter 

description 203 

requesting space for an index 39 
DSP (JES3) 

allowable on PROCESS statement 317 

definition 324 
dsp parameter on PROCESS statement (JES3) 
dummy data set 

bypassing disposition processing 54 

bypassing I/O operations (JES2) 65 

bypassing I/O operations (JES3) 89 

defining 98-99 

definition 324 

reading 99 

suppressing output (JES2) 65 

suppressing output (JES3) 89 

writing 99 
DUMMY parameter on DD statement 

backward references 222 

creating a dummy data set 98 

description 222-223 

nullifying a procedure 222 

suppressing output (JES2) 65 

suppressing output (JES3) 89 
dump, abnormal termination 

definition 324 

high-density 193.1 (VS2.03.810) 

requesting (JES2) 63 

requesting (JES3) 87-88 

storing 185 
DUMP value on CHARS parameter 193.1 (VS2.03.810) 
DYNAM parameter on DD statement 

description 224 

dynamic allocation 41 
dynamic allocation 324 

(see also DYNAM parameter on DD statement and 
DYNAMNBR parameter on EXEC statement) 
dynamic deallocation 324 

(see also FREE parameter on DD statement) 
dynamic support program (DSP) 324 
DYNAMNBR parameter on EXEC statement 

description 1 62 

dynamic allocation 41 



ellipsis 130 

ENABLE operator command (JES3) 276 

END subparameter of FREE parameter 

description 227 

dynamic deallocation 41 
end-of-data-set exits 

for dummy data set 99 
enqueing on a data set 54 
ENDDATASET statement (JES3) 

description 280 

introduction 23 
ENDPROCESS statement (JES3) 281 
ERASE operator command (JES3) 276 
EROPT subparameter of DCB parameter 203 
error option 

(see EROPT subparameter of DCB parameter) 
esoteric name 

(see user-assigned group name) 
EVEN subparameter of COND parameter 

description 159-160 

use of (JES2) 61 

use of (JES3) 82 
Examples 

dependent job control (JES3) 79-81 



disposition processing 56 

generation data sets 1 15 

identifying data sets 50 

obtaining output (JES2) 68-69 

obtaining output (JES3) 93-94 

requesting space 39 

requesting storage 28 

requesting units and volumes 36 

routing a job (JES2) 62 

routing a job (JES3) 85 

unit and volume affinities 35 
exclude particular processors (JES3) 72 
EXCP (execute channel program) subparameters of DCB 

parameter 201-209 
EXEC statement 

cataloged procedure, use with 117 

description 155,319,324 

introduction 21,22 

modifying parameters on 119-121 

parameters, keyword 155 

parameters, positional 155 

restriction on changing PGM parameter 120 
execute statement (EXEC) 

(see EXEC statement) 
execute channel program 

(see EXCP subparameters of DCB parameter) 
execution priority (for ASP only) 

definition 324 

description 77 

(see also JPRTY parameter on MAIN statement (JES3)) 
existing data sets 

default disposition processing 53-54 

volume request 29 
EXPDT subparameter of LABEL parameter 

description 229-231 

use of 49 
EXPDTCHK parameter on MAIN statement (JES3) 

292,294,297 
expiration date 

when DELETE is coded 51-52 

when KEEP is coded 52 

(see also LABEL parameter on DD statement) 
expiration date checking (JES3) (see EXPDTCHK 

parameter on MAIN statement) 
explicit setup (JES3) (see SETUP parameter on MAIN 

statement) 
extending a data set 

additional space 38 

multiple units 32 
external page storage 324 

(see also virtual storage) 
external writer 324 



FAIL operator command (JES3) 276 
FAILURE parameter on MAIN statement (JES3) 

292,294,297 
FCB parameter 

definition 324 

on DD statement 225-226 

on FORMAT PR statement (JES3) 287,288,289 

on OUTPUT statement (JES2) 268,269 

use of (JES2) 68 

use of (JES3) 91 

use of (JES3) 91.0(VS2.03.810) 
FETCH parameter on MAIN statement (JES3) 292,295 
fetching devices 

(see FETCH parameter on MAIN statement (JES3)) 
fixed-length record 

(see RECFM subparameter of DCB parameter) 
FLASH parameter- 
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on DD statement 226.1 (VS2.03.810) 

on FORMAT PR statement (JES3) 287,288-288. 1 ,289 
(VS2.03.810) 

on OUTPUT statement (JES2) 268,268.1 (VS2.03.803) 

use of (JES2) 68-68. 1 (VS2.03.810) 

use of (JES3) 92 (VS2.03.810) 
FLASHC parameter on OUTPUT statement (JES2) 

268,268.1 (VS2.03.803) 
FOLD subparameter of UCS parameter 242 
folding 324 

(see also FOLD subparameter of UCS parameter) 
form name subparameter of SYSOUT parameter 

description 239 

use of (JES2) 67 

use of (JES3) 91 
FORMAT AC statement (JES3) 

description 283-285,282 

output 92-93 
FORMAT NJP statement (JESS) 286,282 
FORMAT statement (JES3) 

AC (TSO on ASP main processor) 93,283-285 

description 282 

introduction 23 

NJP 286,282 

PR (print) 89-92,287-289 

PU (punch) 92,290-291 

use of 89-94 
FORMAT PR statement (JES3) 

description 287-289,282 

output 89-92 
FORMAT PU statement (JES3) 

description 290-291,282 

output 92 
forms (see FORMS parameter and form name 

subparameter) 
forms control buffer feature (see FCB parameter) 
form and character control 

requesting (JES2) 67-68 

requesting (JES3) 90-92 
forms control (see FCB and FORMS parameters) 
forms overflow (JES3) (see OVFL parameter on FORMAT 

PR statment) 
forms overlay (VS2.03.810) 

(see FLASH parameter) 
FORMS parameter 

on FORMAT PR statement (JES3) 287,288 

on FORMAT PU statement (JES3) 290 

on JOBPARM statement (JES2) 265 

on OUTPUT statement (JES2) 268 

on OUTPUT statement (JES2) 268,268.1 (VS2.03.803) 

use of (JES2) 67 

use of (JES3) 91 
FREE operator command (JES3) 276 
FREE parameter on DD statement 

description 227 

dynamic deallocation 41 
FRID subparameter of DCB parameter 203 
FROM parameter on FORMAT NJP statement (JES3) 286 
FUNC subparameter of DCB parameter 203 



GAM subparameters of DCB parameter 201-209 
GDG (generation data groups) 

building a base entry 1 1 1 

creating 111-113 

creating a model data set label 111-112 

data set definition 323 

definition 324 

examples of creating and retrieving 115 

generations of 44 

parameters, creating a GDG 112-113 



parameters, retrieving a GDG 113-114 

restarting a job 114 

retrieving 113-114 
generation data groups 

(see GDG) 
generation data set 324 

(see also GDG) 
generation numbers, relative 44, 1 1 1 
GETMAIN (see ADDRSPC and REGION parameters) 
generic name 

(see device type) 
global processor 

definition 324 

selecting 72 

(see also SYSTEM parameter on MAIN statement 
(JES3)) 
GNCP subparameter of DCB parameter 203 
graphics access method 

(see GAM subparameters of DCB parameter) 
graphic device 

eligible for allocation 29 
group name 324 

(see also user-assigned group name) 
group name subparameter of GROUP parameter 139.0 

(VS2.03.804) 
GROUP parameter on JOB statement 139.0 (VS2.03.804) 
group value subparameter of COPIES parameter 

on DD statement 195-195.0 (VS2.03.810) 

on FORMAT PR statement (JES3) 287,288,289 
(VS2.03.810) 

use of 66.1,90 (VS2.03.810) 
Gil character set (3211) 67,91 



HASP 324 
high-density dump 

requesting (JES2) 63 (VS2.03.810) 

requesting (JES3) 87.0 (VS2.03.810) 

used with CHARS parameter 193. 1 (VS2.03.810) 

used with FCB parameter 225 (VS2.03.810) 
high watermark setup 73,74 

(see also SETUP parameter on MAIN statement (JES3)) 
HN character set (1403) 67,91 
HOLD operator command 251 
HOLD parameter 

delaying the writing of an output data set (JES2) 65 

delaying the writing of an output data set (JES3) 89 

on DD statement 228 

on FORMAT AC statement (JES3) 283,284 

on MAIN statement (JES3) 292,293 
HOLD subparameter of TYPRUN parameter 153 
hold output (see HOLD parameter) 
HOTJOB parameter on MAIN statement (JES3) 

292,294,297 
HI 1 character set (321 1) 67,91 



IBM standard labels 47 

(see also LABEL parameter) 
lEALIMIT program 137,148,157,171 
lEBlMAGE program 

for character arrangement tables 68,91 (VS2.03.810) 

for copy modification modules 66.1,90,231.0 
(VS2.03.810) 
lEFBR 14 program 59,83 

image for printing a data set, requesting 68,91 
image identifier 

(see FCB parameter) 
IN subparameter of LABEL parameter 

description 229-231 

use of 49 
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incremental quantity 

(see secondary quantity) 
index 

description on OUTPUT statement (JES2) 268 

description on SPACE parameter 236 

used with indexed sequential data set 39 
INDEX parameter on OUTPUT statement (JES2) 

268,269 
index print position 268,269 
index area, specifying space for 39 
indexed sequential data set 

area arrangement 109,313 

creating 106-109,39,312 

creating, example of 1 10-1 1 1 

general 106 

index space 39 

parameters, creating 106-108,312 

parameters, retrieving 109-110,312 

retrieving 109-110,312 

retrieving, example of 110-111 

specific tracks 39 

temporary 45 
INOUT specification (OPEN macro instruction) 

for BSAM, overriding 49 
input stream 

definition 25-26,324 

entering data 101,189,25 

entering commands 251 
input/output operations, bypassing 65,89 
input service 324 
input stream 324 

INQUIRY operator command (JES3) 276 
installation-written writer routine 64 
in-stream procedure 

definition of 24,324 

description of 117-128 

example of 128 

passing information 24 

symbolic parameters 123-128 

(see also PEND and PROC statements) 
INT parameter on FORMAT PU statement (JES3) 

290,291 
integrity, data set 

definition 324 

how system processes 55 

insuring 54 
interpret card output (JES3) 92 
introduction 21-26 

INTVL subparameter of DCB parameter 203 
lORATE parameter on MAIN statement (JESS) 

description 292,295 

use of 75 
. ISAM data set 

(see indexed sequential data set) 

J parameter on DATASET statement (JES3) 276 
JCL statements 

fields of 130-131 

how to code 129-134 

introduction 21-22 

no longer supported 3 

requesting listings of (JES2) 63 

requesting listings of (JES3) 87 
I JCLHOLD subparameter of TYPRUN parameter 153 
I (VS2.03.803) 
JCLTEST 84 
JESJCL 283,287 
JESMSG 283,287 
JES2 operator commands 264 
JES2 statements 



coding 263 

description 264-273,324 

example of 26 

introduction . 22 

scheduling a job 57-58 
JES3 statements 

definition 324 

description 276-305 

how to code 275 

introduction 23 

setup 73-75 
job 

assigning class and priority (JES2) 57-58 

assigning class and priority (JES3) 75 

definition 324 

delaying initiation (JES2) 60 

delaying initiation (JES3) 76 

in input stream 25-26 

introduction 21,25-26 
job class 324 

(see also CLASS parameter) 
job class queue 324 
job control language 

definition 324 

introduction 21-22 
job control language statements 324 

(see also JCL statements) 
job entry subsystem (2) 

(see JES2 statements) 
job entry subsystem (3) 

(see JES3 statements) 
job failure 

JES2 recovery 61-62 

JES3 recovery 84-85 
job initiation, delaying (JES2) 60 
job initiation, delaying (JES3) 76 
job journal 324 

(see also JOURNAL parameter on MAIN statement 
(JES3)) 
job library 324 

(see also JOBLIB DD statement) 
job log, JES2 265 
job management 324 
job performance (see PERFORM parameter) 
job priority (see priority) 
job related output 324 
job scheduling 

deadline scheduling (JES3) 75-76 

improving 71-72 

using JES2 and JCL statements 57-58 

using JES3 and JCL statements 71-72 
job selection (JES2) 57-58 
job selection (JES3) 75-77 

(see also MAIN statement (JES3)) 
job setup 

(see SETUP parameter on MAIN statement (JES3)) 
JOB statement 

description 135,318,324 

examples of 135 

introduction 21,22 

parameters, keyword 135 

parameters, positional 135 
job step 

definition 324 

dispatching priority (JES2) 58 

dispatching priority (JES3) 76-77 

in input stream 25-26 

introduction 2 1 

performance 58,76 
job step task 324 
JOBCAT DD statement 
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description 177 

master catalog 98 

private catalog 98 

VSAM 102-105 
jobclass subparameter of CLASS parameter 138 
JOBLIB DD statement 

concatenating private libraries 97-98 

creating a private library 95-96 

description 178-180 

effect with STEPLIB DD statement 96-97 

placement of statement in job 95 

retrieving a private library 96-97 

when COND=ONLY is coded 160 
jobname 324 
JOBPARM statement (JES2) 

COPIES parameter 66 

description 265-266 

FORMS subparameter of OUTPUT statement 268 

introduction 22 - 
JOBSTEP parameter on MAIN statement (JES3) 292,294 
JOURNAL parameter on MAIN statement (JES3) 

292,294,297 
JPRTY parameter on MAIN statement (JES3) 

description 292,295,298 

execution priority for ASP 77 

K 324 

KEEP subparameter of DISP parameter 

description 214-216 

use of 52 
keeping a data set 

(see KEEP subparameter of DISP parameter) 
KEYLEN subparameter of DCB parameter 204 
keylength 

(see KEYLEN subparameter of DCB parameter) 
keyword 324 
keyword parameters 

definition 131,324 

on DD statement 175 

on EXEC statement 155 

on JOB statement 135 

label (see LABEL parameter on DD statement) 
LABEL parameter on DD statement 

description 229-23 1 

for indexed sequential data sets 107 

for generation data sets 1 13,1 14 

retention period 52 

use of 47-49 
label type subparameter of LABEL parameter 

description 229,230 

specified for direct access 29 

specified for tape 29 

use of 47-48 
length restriction 

for symbolic parameters 125 
lengthening a data set 

additional space 37-39 

exclusive control 54 

multivolume data set 3 1 

(see also MOD subparameter of DISP parameter) 
library 

placing a cataloged procedure in 118 

private 95-98 

temporary 95,98 

(see also JOBLIB and STEPLIB DD statements) 
LIMCT subparameter of DCB parameter 204 
limiting output records 

(see OUTLIM parameter on DD statement) 



LINDEX parameter on OUTPUT statement (JES2) 

268,269 
LINECT parameter on JOBPARM statement (JES2) 265 
LINES parameter 

on JOBPARM statement (JES2) 265 

on MAIN statement (JES3) 292,293,296 
listings of JCL statements and system messages 

cataloged and in-stream procedures 117 

requesting (JES2) 63 

requesting (JES3) 87 

(see also MSGCLASS and MSGLEVEL parameters on 
JOB statement) 
local devices 324 
local processor 324 

(see also SYSTEM parameter on MAIN statement 
(JES3)) 
local station 324 
LOCAL subparameter 

on OUTF'UT stiatement (JES2) 268 

on OUTPUT statement (JES2) 268.1 (VS2.03.803) 

on ROUTE statement (JES2) 271 
LOG operator command 251 
logical record length 325 

(see also LRECL subparameter of DCB parameter) 
logical region 325 
loosely-coupled multiprocessing 

definition 325 

description 7 1 
LRECL subparameter of DCB parameter 204 
LREGION parameter on MAIN statement (JES3) 

292,295.298 
LTM subparameter of LABEL parameter 229 



main service 325 

MAIN paranieter on FORMAT AC statement (JES3) 

283,284 
MAIN statement (JES3) 

deadline scheduling 75-76 

description 292-299 

introduction 23 

job processing balance 75 

job setup 73 

output 92 

updating a procedure library 1 1 8 
mass storage system 

definition 325 

mass storage volume groups 40-41 

space requests 41 

volume requests 40 

MSVGP requests '232-233 
mass storage volumes 

specifying SPACE parameter 41 

specifying UNIT parameter 40 

specifying VOLUME parameter 40 

specif yirig M§VGP parameter 232-233 
mass §torage volume groups 40-41 

(see also MSVGP parameter) 
memory 

(see address space) 
message class parameter 

(see MSGCLASS parameter on JOB statement) 
message level parameter 

(see MSGLEVEL parameter on JOB statement) 
MESSAGE operator command (JES3) 276 
message queue records 

(see THRESH subparameter of DCB parameter) 
MESSAGE statement 

description 267 

introduction 22 
message, systern 63,87 
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minimum region size 27-28 

MOD subparameter of DISP parameter 

description 214 

use of 51 
MODE parameter on DATASET statement (JES3) 278 
MODE subparameter of DCB parameter 204 
mode for card reader/punch 

(see MODE subparameter of DCB parameter) 
MODIFY operator command 

forJCL 251 

for JES3 276 
MODIFY parameter 

on DD statement 231.0 (VS2.03.810) 

on FORMAT PR statement (JES3) 287,288.1,289 
(VS2.03.810) 

on OUTPUT statement (JES2) 268,269 (VS2.03.803) 

use of (JES2) 66.1 (VS2.03.810) 

use of (JES3) 90 (VS2.03.810) 
modifying a cataloged procedure 118 

(see also UPDATE parameter on MAIN statement 
(JES3)) 
MODTRC parameter on OUTPUT statement (JES2) 

268,269 (VS2.03.803) 
module name subparameter of MODIFY parameter 

on DD statement 231.0 (VS2.03.810) 

on FORMAT PR statement (JES3) 287,288.1 
(VS2.03.810) 

on OUTPUT statement (JES2) 268,269 (VS2.03.803) 
MONITOR operator command 251 
MOUNT operator command 251 
MSGCLASS parameter on JOB statement 

description 140 

printing output (JES2) 63-64 

printing output (JES3) 87-88 
MSGLEVEL parameter on JOB statement 

description 141 

listing JCL and messages (JES2) 63 

listing JCL and messages (JES3) 87 
MSS (see mass storage system) 
MSVGP parameter on DD statement 

defining mass storage volumes 40-41 

description 232-233 
multiple copies, output data set 

(see COPIES parameter) 
multiple units 32 
muitivolume data sets 31 
mutually exclusive parameters 

definition 325 

table of 314 

used to override a parameter in a procedure 121-122 
MXIG subparameter of SPACE parameter 236,238 



N subparameter of BURST parameter 

on DD statement 193.0 (VS2.03.810) 

on OUTPUT statement (JES2) 268 (VS2.03.803) 
name of a data set 43 
name field in control statements 130 
national character set 133 
NC subparameter of RD parameter 

on EXEC statement 169-170 

on JOB statement 146-147 
NCK subparameter of AMP parameter 191 
NCP subparameter of DCB parameter 204 
NET statement for JES3 

description 300-302 

introduction 23 

dependent job control 77-81 

how to code 78-79 

examples of 79-81 
NETID parameter on NET statement (JES3) 



description 300,301 

use of 77-81 
NETREL parameter on NET statement (JES3) 

description 300,301,302 

use of 77-81 
network job processing (JES3) 81-82 

(see also FORMAT NJP statement) 
NEW subparameter of DISP parameter 

description 214-215 

exclusive control 54 

use of 50-5 1 
new data sets 

default disposition 53-54 

on direct access devices 36 

specifying status of 50-51 

volume request 29-30 
new password subparameter of PASSWORD parameter 

142.1 (VS2.03.804) 
NHOLD parameter on NET statement (JES3) 

description 300,301 

use of 77-81 
NJP parameter on FORMAT statement (JES3) 286,282 

(see also network job processing) 
NJPCLASS parameter on MAIN statement (JES3) 

description 292,294,297 

use of 82 
NL subparameter of LABEL parameter 229-230 
NO subparameter of HOLD parameter 228 
NOLOG parameter on JOBPARM statement (JES2) 265 
nonpageable dynamic area 27,325 
nonsharable volume 

definition 325 

for muitivolume data set 31 
nonspecific volume requests 

definition' 325 

mass storage volumes 40-41 

space requests for 29 

types of 30 
nonstandard job processing (JES3) (see PROCESS 

statement) 
nonstandard labels 47-48 

(see also LABEL parameter on DD statement) 
nontemporary data set 43-44,325 
NOPWREAD subparameter of LABEL parameter 

description 229-23 1 

use of 48-49 
normal disposition of data sets 51-53 
NORMAL parameter on NET statement (JES3) 

description 300 

use of 77-81 
notational conventipns 129-130 
NOTIFY parameter on JOB statement 142 
NR subparameter of RD parameter 

on EXEC statement 169 

on JOB statement 146 
NRC subparameter of AMP parameter 191-192 
NRE subparameter of AMP parameter 191-192 
NSL subparameter of LABEL parameter 229-230 
NTM subparameter of DCB parameter 204 
null statement 

definition 325 

description 257 

introduction 21 
NULLFILE. assign to DSNAME 99 

(see also DUMMY parameter) 
nullifying parameters in a procedure 

DCB parameter 122 

DUMMY parameter 122 

on DD statements 121-122 

on EXEC statements 119-121 

symbolic parameters 123-128 
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old data sets 

(see OLD subparameter of DISP parameter) 
OLD subparameter of DISP parameter 

description 214 

use of 50-51 
ONLY subparameter of COND parameter 

on EXEC statement 159-160 

use of 61,82 
OPEN/CLOSE/EOV trace option 

(see DIAGNS subparameter of DCB parameter) 
operand field in control statements 131 
operating system (OS) 325 
operation field in control statements 131 
operator commands 

forJCL 251 

for JES2 264 

for JES3 276 
OPERATOR statement for JES3 

description 303 

introduction 23 
operator subparameter of COND parameter 

on EXEC statement 1 59 

on JOB statement 139 
operator verification 

of image 68,91 

of special character set 67,91 
OPHOLD parameter on NET statement (JES3) 

description 300,301 

use of 77-81 
OPTCD subparameter 

of AMP parameter 191-192 

of DCB parameter 205-206 
optional services 

(see OPTCD subparameter) 
ORG parameter on MAIN statement (JES3) 292,295,297 
OUT subparameter of LABEL parameter 

description 229,231 

use of 49 
OUTIN specification for BSAM, overriding 49 
OUTLIM parameter on DD statement 

description 234 

limiting output records (JES2) 66 

limiting output records (JES3) 90 
output (JES2) 

assigning to classes 64 

cataloged and in-stream procedures 123 

data sets 64-68 

delaying 65 

for 3800 printer (see OUTPUT statement) (VS2.03.803) 

limiting 66 

listing JCL messages 63 

obtaining 63-69 

printing dumps 63-64 

writing 64-69 
output (JES3) 

assigning to classes 88 

cataloged and in-stream procedures 123 

data sets 88-92 

delaying 89 

for 3800 printer (see FORMAT PR statement) 
(VS2.03.810) 

limiting 90 

listing JCL messages 87 

obtaining 87-94 

printing dumps 87-88 

remote job processing 93 

writing 88-92 
output classes (JES2) 

assigning data sets to 64 

assigning messages to 63 

definition 325 



output classes (JES3) 

assigning data sets to 88 

assigning messages to 87 

definition 325 
output class subparameter of MSGCLASS parameter 

description 140 

use of (JES2) 63-64 

use of (JES3) 87-88 
output data 325 
output data set 

allocating space for (see SPACE parameter) 

conditional disposition (see COND and DISP 
parameters) 

copies of (see COPIES parameter) 

creating 308-309 

disposition (see DISP parameter) 

lengthening 237-238,311 

routing of (see SYSOUT parameter) 

stackers for (VS2.03.810) 

(see BURST and STACKER parameters) 

status (see DISP parameter) 

unit information (see UNIT parameter) 

volume information (see VOLUME parameter) 

with UCS feature (see UCS parameter) 
output device 

(see system output device) 
output form (see FORMS parameter and form name 

subparameter) 
output listing 

definition 325 

dumps 63-64,87-88 

identifying cataloged and in-stream procedures 123 

JCL statements 63,87 

suppressing of (JES2) 65 

suppressing of (JES3) 89 

system messages (JES2) 63 

system messages (JES3) 87 
output service 325 
OUTPUT statement (JES2) 

description 268-269 

introduction 22 

use of 67-68 
override 

of catalog procedures 24,119-123 

of original secondary quantity request for space 38 

of symbolic parameters 123-128 

parameters in a procedure 

on a DD statement 121-123 
on an EXEC statement 119-121 
overflow area 

for indexed sequential data set 106 
overlay name subparameter of FLASH parameter 

on DD statement 226. 1 (VS2.03.810) 

on FORMAT PR statement (JES3) 287,288.1 
(VS2.03.810) 

on OUTPUT statement (JES2) 268,268.1 (VS2.03.803) 
OVFL parameter on FORMAT PR statement (JES3) 

description 287,288,289 

description 287,288,289.0 (VS2.03.810) 

use of 92 



P subparameter of UNIT parameter 

description 244 

use of 32 
page 27,325 

PAGEADD operator command 25 1 (VS2.03.807) 
parameters 

adding, nullifying, overriding 125-128 

in cataloged or in-stream procedure 117-124 

notation for defining 129 
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symbolic 123-128 

on DD statement 121-123 

on EXEC statement 119-121 
parentheses 

to enclose subparameter list 129 

inclusion in variables 126-128 
FARM parameter on EXEC statement 

description 163-164 

modified in procedure 119-121 

passing information 59 
partitioned data set 

absolute track allocation 39 

adding member to 44-45 

concatenating 122 

creating 43-44,308 

definition 325 

directory space for 38 

lengthening 311 

member name 44 

nontemporary name 43 

retrieving a member of 43-44,310 

temporary name 45 
PASS subparameter of DISP parameter 

description 214,215 

use of 53,51 
passed data set 325 

(see also PASS subparameter of DISP parameter) 
passing information to a job (JES2) 59 
passing information to a job (JES3) 83 
passing a private library 95-98 

(see also JOBLIB DD and STEPLIB DD statements) 
PASSWORD parameter on JOB statement 142. 1 

(VS2.03.804) 
password protection 

(see PASSWORD and NOPWREAD subparameters of 
LABEL parameter) 
PASSWORD subparameter of LABEL parameter 

description 229,231 

use of 48-49 
PAUSE statement (JES3) 

description 304 

introduction 23 
PC AN character set (1403) 67,91 
PCHN character set (1403) 67,91 
PCI subparameter of DCB parameter 206 
PEND statement 

definition 325 

description 259 

introduction 21 

use of 1 17 
performance (see PERFORM parameter) 
PERFORM parameter 

on EXEC statement 165 

on JOB statement 143 

use of (JES2) 58 

use of (JES3) 76 
permanently resident volume 

definition 325 

private volume not demounted 30 
PGM parameter on EXEC statement 

description 166-167 

for private library 95 

identifying the program 59,83 

JCLTEST 84 

restriction, cataloged procedures 117 
physical record 325 
PN character set (1403) 67,91 
positional parameters 

definition 131,325 

DUMMY parameters 99 

on DD staterrient 175 



on EXEC statement 155 

on JOB statement 135 

in operand field 131 

symbolic 124 
positioning, multivolume 31 

PR parameter on FORMAT statement (JES3) 287-289,282 
predecessor job, dependent job control 77-81 
primary quantity subparameter of SPACE parameter 

description 236-237 

satisfying request 37-39 
prime area 106,219 
PRINT parameter 

on i^ORMAT AC statement (JES3) 283,284 

on ROUTE statement (JES2) 271 
print output (JES3) (see FORMAT PR statement) 
PRINTER (JES2) 

on OUTPUT statement 268 

on ROUTE statement 271 
printer form control 

for JES2 67-68 

for JES3 90-92 
printer train (JES3) 91 
printers 

character sets for 67,91 

images, requesting 68,91 

(see also UCS parameter on DD statement) 

(see also 3800 Printing Subsystem (VS2.03.810)) 
PRINTR (JES2) 

on OUTPUT statement 268 

on ROUTE statement 271 
priority 

aging (JES3) 75 

automatic priority group 58,76-77 

definition 325 

dispatching (see DPRTY paramter on EXEC statement) 

for ASP main processors (see JPRTY parameter on 
MAIN statement (JES3)) 

output (see PRTY parameter on FORMAT PR statement 
(JES3)) 

selection of jobs (see PRIORITY statement (JES2) and 
PRTY parameter on JOB statement (for JES3)) 
PRIORITY statement (JES2) 

description 270 

introduction 22 

job selection 58 
private catalogs 

(see JOEiCAT and STEPCAT DD statements) 
private library 

adding members to 96 

concatenating 97-98 

creating 95-96 

defining JES3 catalog procedure 296,298 

definition 325 

retrieving 96-97 

with PGM parameter 59 

using 95 

(see also JOBLIB DD and STEPLIB DD statements) 
PRIVATE subparameter of VOLUME parameter 

description 247,248 

use of 30 
private volume 325 

(see also PRIVATE subparameter of VOLUME 
parameter) 
FROC pararheter 

on MAIN statement (JES3) 292,296,298 

on EXEC statement 168 
PROC statement 

definition 325 

description 261-262 

introduction 21 

symbolic parameter 123-128 
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iiseof 117-122 
procedure end 

(see PEND statement) 
procedure library (SYSl.PROCLIB) 

definition 24,325 

cataloged procedure 24, 1 1 7- 1 28 
procedure statement 325 

(see also PROC statement) 
procedure step 117,325 
PROCESS statement (JES3) 

description 305-306 

use of 23 
PROCLIB parameter on JOBPARM statement 265,266 
program, calling 59 

program name subparameter of SYSOUT parameter 239 
programmer's name parameter on JOB statement 144 
PRTSP subparameter of DCB parameter 207 
PRTY parameter on FORMAT PR statement (JES3) 

287,288 
PRTY parameter on JOB statement 

description (J ES2) !44.!(VS2,03.803) 

description (JES3) 145 

selection of jobs (JES3) 75 
PU parameter on FORMAT statement (JES3) 

290,291,282 
public volume 

definition 325 

requesting 30 

(see also VOLUME parameter on DD statement) 
PUNCH (JES2) 

on OUTPUT statement 268 

on ROUTE statement 271 
punching a data set (JES3) (see FORMAT PU statement) 
Pll character set (2311) 67,91 



QISAM subparameters of DCB parameter 201-209 
(see also indexed sequential data set) 

QN character set (1403) 67,91 

QNAME parameter on DD statement 235 

QSAM subparameters of DCB parameter 201-209 

qualified data set name 45,325 

queue 325 

queued indexed sequential access method 

(see QISAM subparameters of DCB parameter) 

queued sequential access method 

(see QSAM subparameters of DCB parameter) 



R subparameter (JES2) 

of OUTPUT statement 268.1 (VS2.03.803) 

of ROUTE statement 27 1 (VS2.03.803) 
R subparameter of RD parameter 

on EXEC statement 169 

on JOB statement 146 
RACE (see GROUP, PASSWORD, and USER parameters 

on the JOB statement) (VS2.03.804) 
RCK subparameter of AMP parameter 191 
RD parameter 

on EXEC statement 169-170 

on JOB 'statement 146-147 

use of (JES2) 62 

use of (JES3) 85 
reader/interpreter 325 
reading a data set 

dummy 99 

multivolume 31 

shared control 55 
READ/WRITE macros before a CHECK macro 

(see NCP subparameter of DCB parameter) 
REAL subparameter of ADDRSPC parameter 



on EXEC statement 157 

on JOB statement 137 

requesting storage 27-28 
real storage 325 

<see also REGION parameter) 
RECFM subparameter 

of AMP parameter 191-192 

of DCB parameter 207-208 
record 325 
record format 

(see RECFM subparameter of DCB parameter) 
record key position 

(see RKP subparameter of DCB parameter) 
record length 

(see LRECL subparameter of DCB parameter) 
REF subparameter of VOLUME parameter 

description 247,249 

specific volume request 29-31 

volume affinity 33-35 
references, backward 

(see backward references) 
region 325 
REGION parameter 

on EXEC statement 171 

on JOB statement 148-149 

requesting storage 27-28 
region request, example 28 
region size, default 148,171 
relational operators on the COND parameter 

on EXEC statement 159 

on JOB statement 139 

use of (JES2) 61-62 

use of (JES3) 82 
relative generation number 112 
relative track number 

(see address subparameter of SPACE parameter) 
RELEASE operator command 251 
RELEASE parameter on NET statement (JES3) 

description 300,301 

use of 77-81 
releasing space 

deleting a data set (see DELETE subparameter of DISP 
parameter) 

unused space (see RLSE subparameter of SPACE 
parameter) 
RELSCHCT parameter on NET statement (JES3) 

description 300,301,302 

use of 77-81 
remote devices 325 
remote job entry 325 
remote job processing (JES3) 

definition 326 

description 93 
REMOTE parameter on SIGNON statement (JES2) 273.1 

(VS2.03.803) 
remote station 326 
remote terminal 

on OUTPUT statement 268 

on ROUTE statement 271 
removable volume (see VOLUME parameter on DD 

statement) 
replacing variable data (VS2.03.810) 

(see MODIFY parameter) 
REPLY operator command 25 1 
repositioning, tape 

(see REPOS subparameter of DCB parameter) 
requesting storage (see REGION parameter) 
RESERVE subparameter of DCB parameter 208 
reserved volumes 

definition 326 

private volume not demounted 30 
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RESET operator command 251 
resources 

definition 326 

dynamic allocation of 41-42 

requesting 27-56 
restart 

definition 326 

for generation data group 1 14 

forJES2 61-62 

for JES3 84-85 

(see also RD parameter, RESTART parameter on JOB 
statement, and SYSCHK DD statement) 
restart facility (see checkpoint/restart facility) 
RESTART operator command (JES3) 276 
RESTART parameter on JOB statement 

description 150-151 

use of (JES2) 61-62 

use of (JES3) 84-85 

(see also SYSCHK DD statement) 
RESTART parameter on JOBPARM statement (JES2) 

265,266 (VS2.03.803) 
RETAIN subparameter of VOLUME parameter 

description 247,248 (VS2.03.804) 

use of 30 (VS2.03.804) 
retaining tape volumes (VS2.03.804) 

(see RETAIN subparameter of VOLUME parameter) 
retention period 

for DELETE 51-52 

for KEEP 52 
RETPD subparameter of LABEL parameter 

description 229,230,231 

use of 49 
return code 

definition 326 

conditional disposition (JES2) 61 

conditional disposition (JES3) 82 
return code tests 61 
rewinding tapes 

for DELETE 51-52 

for KEEP 52 

for PASS 53 
RINGCHK parameter on MAIN statement (JES3) 292,296 
RKP subparameter of DCB parameter 209 
RLSE subparameter of SPACE parameter 236,238 
RM subparameter (JES2) 

of OUTPUT statement 268. 1 (VS2.03.803) 

of ROUTE statement 271 (VS2.03.803) 
RMT subparameter 

of OUTPUT statement 268 

of OUTPUT statement 268. 1 (VS2.03.803) 

of ROUTE statement 271 
RN character set (1403) 67,91 
RNC subparameter of RD parameter 

on EXEC statement 169,170 

on JOB statement 146 
ROOM parameter on JOBPARM statement (JES2) 265 
ROUND subparameter of SPACE parameter 

description 236 

requesting space 37-39 
ROUTE statement (JES2) 

description 271-272 

introduction 22 

routing output 68 
routing a job (JES2) 

cuiidilionai execution 61 

delaying job initiation 60 

example of 62 

job scheduling 57-58 

passing information 59-60 

restarting 61-62 
routing a job (JES3) 



allocating data resources 72-75 

conditional execution 82 

delaying job initiation 89 

example of 85 

JES3 setup 73-75 

job scheduling 71-72 

passing information 83-84 

restarting 84-85 

selecting a job 75 

selecting a processor 72 
routing output data sets (JES2) 68 
routing output data sets (JES3) 92-93 
routing system messages (JES2) 63 
routing system messages (JES3) 87 
routing TSO output (JES3) 93 

scheduling jobs (see job scheduling) 
scheduling priority 326 

(see also priority) 
SCAN subparameter of TYPRUN parameter 153 
scanning JCL for syntax errors 153 
scanning job without execution 84 
scratch volume 

(see storage volume) 
secondary quantity subparameter of SPACE parameter 

description 236,237 

requesting space 37-39 
secondary request for space 

(see secondary quantity subparameter of SPACE 
parameter) 
selecting jobs (JES2) 57-58 
selecting jobs (JES3) 75-82 
selecting a processor (JES3) 72 

(see also SYSTEM and TYPE parameters on MAIN 
statement) 
SEND operator command 

for JCL 251 

for JES3 276 
separating groups of data 189,196 
SEQUENCE macro 

(see RESERVE subparameter of DCB parameter) 
sequence of DD statements 

concatenated data sets 97-98 

sharing cylinders 37 
sequence number subparameter of LABEL parameter 

definition 229,230 

use of 47 
sequential data set 326 
SER subparameter of VOLUME parameter 

description 247,249 

specific volume request 29 
SET operator command 25 1 
SETDMN operator command 25 1 (VS2.03.807) 
setup of devices (JES3) 

description 73-75 

with conditional execution 82 
SETUP parameter on MAIN statement (JES3) 

description 292,294,297 

use of 73 
SETUP statement (JES2) 

delaying job initiation 60 

description 273 

introduction 22 
seven track tape 

(see TRTCH subparameter of DCB parameter) 
sharing cylinders 37 
sharing a data set 

(see SHR subparameter of DISP parameter) 
sharing a library 96 
sharing units 
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(see unit affinity) 
sharing volumes 

(see volume affinity) 
SHR subparameter of DISP parameter 

data set status 50-51 

description 214,215 

shared control 55 
SIGNOFF statement (JES2) 273.0 (VS2.03.803) 
SIGNON statement (JES2) 273.1 (VS2.03.803) 
SL subparameter of LABEL parameter 229,230 
SN character set (1403) 67,91 
space 

for directory 38 

for index 39 

for non-VSAM data sets on mass storage volumes 41 

for partitioned data sets 38 

primary requests 37-38 

secondary requests 37-38 

specific tracks 39 
SPACE parameter on DD statement 

creating a private library 95-96 

description 236-238 

for non-VSAM data sets 37-39 

for generation data groups 112 

for indexed sequential data set 109 

index subparameters 39 

requesting space 37-39 

storing a dump 1 85 

using mass storage volumes 40-41,237 
space on a printer 

(see PRTSP subparameter of DCB parameter) 
special characters 133-134 
special character set (see special characters) 
special data sets 

dummy 98 

in the input stream 101 

ISAM 106-111 

generation data groups (GDG) 111-115 

private and temporary libraries 95-98 

virtual input/output (VIO) 100-101 

VSAM 102-105 
specific image 

(see FCB parameter) 
specific tracks 

for partitioned data set 39 

how to request 36-39 

restrictions 39 
specific volume request 

definition 326 

for mass storage volumes 40 

restriction using multi-device type VSAM data set 103 

system action 29,39 
specifying device for an output data set (JES2) 64 
specifying device for an output data set (JES3) 72-75 
SPLIT parameter on DD statement 

value converted to space request 3,37 
spooled data set 326 

STACK subparameter of DCB parameter 209 
stacker bin 

(see STACK subparameter of DCB parameter) 
STACKER parameter on FORMAT PR statement (JES3) 

287,288,92 (VS2.03.810) 
stackers for printed output (VS2.03.810) 

(see BURST and STACKER parameters) 
standard job 23,326 

standard labels (see SL subparameter of LABEL parameter) 
START operator command 

forJCL 251 

for JES3 276 
status, data set 50-51 
STDl, standard FCB image 68,91,225 



STDl, standard FCB image 68,91.0,225 (VS2.03.810) 
STD2, standard FCB image 68,91,225 
STD2, standard FCB image 68,91.0,225 (VS2.03.810) 
STD3, standard FCB image 68,91.0,225 (VS2.03.810) 
step restart 

definition 326 

for generation data group 1 14 

use of (JES2) 61-62 

use of (JES3) 84-85 

(see also RESTART parameter on JOB statement and 
RD parameter) 
STEPCAT DD statement 

description 181 

master catalog 98 

private catalog 98 

VSAM 102-105 
STEPLIB DD statement 

defining and retrieving private library 95-97 

concatenating private libraries 97-98 

description 182-184 

effect with JOBLIB DD statement 96-97 
stepname 

assigning 155 

definition 326 
STOP operator command 251 
STOPMN operator command 251 
storage (see REGION parameter) 
storage volume 326 

STRNO subparameter of AMP parameter 191,192 
SUBALLOC parameter on DD statement 

value converted to space request 3,37 
subparameter, definition 131 
successor job 

dependent job control 77-81 

early setup of 77 
SUL subparameter of LABEL parameter 229,230 
suppressed processing, data set 99 
suppressed writing, data set (JES2) 65 
suppressed writing, data set (JES3) 89 
SWITCH operator command (JES3) 276 
symbolic parameters 

assigning values to 126-128 

default values 126 

definition 326 

example of 128 

nullifing 127 

use of commas 124-126 

with PROC statement 168 
SYNAD subparameter of AMP parameter 191,193 
syntax 

checking 59,153 

for JES2 263 

for JES3 275 
SYSABEND parameter on DD statement 

description 185-186 

requesting abnormal termination dumps (JES2) 63-64 

requesting abnormal termination dumps (JES3) 87-88 
SYSAFF parameter on JOBPARM statement (JES2) 265 
SYSCHK DD statement 

description 187-188 

use of (JES2) 62 

use of (JES3) 85 

(see also RESTART parameter on JOB statement) 
SYSOUT parameter on DD statement 

description 239-240 

multiple copies of output 66,90 

print a dump 63-64,87-88 
system affinities (JES2) 

(see SYSAFF parameter on JOBPARM statement) 
system generation 326 
system library (SYSl.LINKLIB) 326 
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system messages 326 

(see also MSGLEVFL parameter on JOB statement) 
system output device 63,87,326 
SYSTEM parameter on MAIN statement (JES3) 

description 292,293,296 

use of 72 
system resources manager 326 
SYSUDUMP parameter on DD statement 

description 185-186 

requesting abnormal termination dump (JES2) 63-64 

requesting abnormal termination dump (JES3) 87-88 
SYSl.LINKLIB data set 

(see system library) 
SYSI.PROCLIB data set 

(see procedure library) 

table name subparameter of CHARS parameter 

on DD statement 193.1 (VS2.03.810) 

on FORMAT PR statement (JES3) 287,288,289 
(VS2.03.810) 
table reference character 68,91,205,326 (VS2.03.810) 

(see also trc subparameter of MODIFY) 
tape density 

(see DEN subparameter of DCB parameter) 
tape device 

eligible for allocation 29 
tape labels, ANSI 

(see LABEL parameter on DD statement) 
tapemark 47-49 
task 326 
TCAM 

NOTIFY parameter 142 

QNAME parameter 235 

TERM parameter 241 

TCAM subparameters of DCB parameter 201-209 
telecommunication access method 

(see TCAM subparameters of DCB parameter) 
teleprocessing device 29 
temporary data set 

creating 44-45 

definition of 44,326 

deletion, conditions of 45 

DSNAME parameter, use of 46 

member name 45 

specifying disposition 215 

VIO, use of 100-101 
temporary library 

definition of 98,326 

with PGM parameter 166 
TERM parameter on DD statement 241 
testing JCL without execution 84 

(see also PGM parameter on EXEC statement) 
THRESH subparameter of DCB parameter 209 
TIME parameter 

on EXEC statement 172-173 

on JOB statement 152 

on JOBPARM statement (JES2) 265,266 
time-dependent program 

requesting real storage 27 
time limit for CPU 

on EXEC statement 172 

on JOB statement 152 
TN character set ( 1 403 ) 67 ,9 1 
TRACE subparameter of AMP parameter 191,193 
track number, relative 

(see address subparameter of SPACE parameter) 
tracks 

capacities 316 

space requests 37-38 

description 236,326 



cylinder index 

(see NTM subparameter of DCB parameter) 

overflow 

(see CYLOFL subparameter of DCB parameter) 

searching 

(see LIMCT subparameter of DCB parameter) 
TRAIN parameter on FORMAT PR statement (JES3) 

287,288,289 
trc subparameter of MODIFY parameter 

on DD statement 231.0 (VS2.03.810) 

on FORMAT PR statement (JES3) 287,288.1,289 
(VS2.03.810) 
TRK subparameter of SPACE parameter 

space requests 37 

description 236 
TRTCH subparameter of DCB parameter 209 
TSO on an ASP main processor 93 

(see also FORMAT AC and MAIN statements (JES3)) 
TYPE parameter on MAIN statement (JES3) 

description 292,294 

defining control program 72 
TYPRUN parameter on JOB statement 

delaying job initiation (JES2) 60 

delaying job initiation (JES3) 76 

description 153 
Til character set (3211) 67,91 



U subparameter (JES2) 

of OUTPUT statement 268. 1 (VS2.03.803) 

of ROUTE statement 271 (VS2.03.803) 
UCS (universal character set) 

(see UCS parameter) 
UCS parameter 

on DD statement 242-243 

on OUTPUT statement (JES2) 268,269 

use of (JES2) 67 

use of (JES3) 91 
uncataloging a data set 

(see UNCATLG subparameter of DISP parameter) 
UNCATLG subparameter of DISP parameter 

description 214,215 

use of 53 
unit 

definition 28,326 

information from other than UNIT parameter 32 

specifying output device 64 

type of unit you can specify 31 

(see also UNIT parameter on DD statement) 
unit address subparameter of UNIT parameter 

definition 326 

description 244 

use of 3 1 
unit affinity 326 

(see also AFF subparameter of UNIT parameter) 
unit count subparameter of UNIT parameter 244 
unit information, other than UNIT parameter 32 
unit of measurement 

cylinders, blocks and tracks 37-39 
unit override 246 
UNIT parameter on DD statement 

creating a private library 95-96 

description 244-246 

generation data groups 112-114 

indexed sequential data sets 107-109 

multiple units 31 

requesting units 31-33 

unit affinity 33-35 

storing a dump 63-64,87-88 

using mass storage volumes 40-41 

write output data set 64,88 
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unit record device 29 
universal character set 326 

(see also UCS parameter) 
unlabeled tapes (see LABEL parameter on DD statement) 
UNLOAD operator command 251 
UPDATE parameter on MAIN statement (JESS) 

description 292,296,298 

use of 118 
USER parameter 

on FORMAT AC statement (JES3) 283,284 

on JOB statement 153.0 (VS2.03.804) 

on MAIN statement (JES3) 292,296 
user-assigned group name subparameter of UNIT parameter 

definition 326 

description 244,245 

use of 31 
user labels (see LABEL parameter on DD statement) 
userid subparameter of USER parameter 153.0 
(VS2.03.804) 



V format 

(see RECFM subparameter of DCB parameter) 
V=R dynamic area 

(see nonpageable dynamic area) 
V=V 

(see virtual storage) 
VARY operator command 

forJCL 251 

for JES3 276 
VERIFY subparameter 

of FCB parameter 225 

of UCS parameter 242 
VIO (see virtual input/output) 
VIRT subparameter of ADDRSPC parameter 

on EXEC statement 157 

on JOB statement 1 37 

requesting storage 27-28 
virtual direct access device 

(see mass storage volumes) 
virtual input/output (VIO) 

definition 326 

for temporary data sets 100-101 
virtual storage 326 

(see also REGION parameter) 
virtual storage access method (VSAM) 102-105 
virtual volumes 

mass storage system 40-41 

(see also MSVGP parameter on DD statement) 
VOL parameter on DD statement 

(see VOLUME parameter on DD statement) 
volume 

deferred mounting 32 

definition 326 

maximum volume request 30 

(see also VOLUME parameter on DD statement) 
volume affinity 

definition 30,326 

how to request 30-31,33-35 
volume count subparameter of VOLUME parameter 

maximum number of volumes you can request 30 

description 247,248 
VOLUME parameter on DD statement 

creating a private library 95 

demounting of volumes 30 

description 247-250 

generation data groups 114 

ISAM requirement for 107-110 

nonspecific volume request 29-30 

for multivolume data set 31 

for private volumes 30 



for volume affinity 30-31,33-35 

specific volume request 29 

using mass storage volumes 40-41 
volume sequence number subparameter of VOLUME 
parameter 

description 247,248 

use of 30 
volume serial number 

subparameter of VOLUME parameter 247,249 

parameter on SETUP statement (JES2) 273 
volumes, requesting 

(see VOLUME parameter) 
volume table of contents 326 
VSAM (virtual storage access method) 

for private catalogs 98 

processing VSAM data sets 102-105 



wait-state time limit 

(see TIME parameter on JOB and EXEC statement) 
work station, controlling output to 68,92,326 
working set 326 

WRITELOG operator command 251 
writing a dummy data set 99 
writing output data sets 

for JES2 64-68 

forJES3 87-93 



XN character set (1403) 67,91 
XX (cataloged procedure) 123 
XX* (cataloged procedure) 123 
X/ (cataloged procedure) 123 



Y subparameter of BURST parameter 
on DD statement 193.0 (VS2.03.810) 
on OUTPUT statement (JES2) 268 (VS2.03.803) 

YES subparameter of DD HOLD parameter 228 

YN character set (1403) 67,91 



6, FCB image 68 
8, FCB image 68 
1403 printer 

requesting a special character set 67,91 

requesting specific image 68,91 
1440 

(see TIME parameters on JOB and EXEC statements) 
321 1 printer 

requesting a special character set 67,91 

requesting specific image 68,91 
3330 model 1 1 

coding 245 

track capacities 316 
3330V virtual volume 232,40 
3340 fixed head feature 32 
3348 model 70F data module 32 
3525 punch interpretation 92 
3540 diskette reader writer 45-46,189,196 
3800 Printing Subsystem 

bursting the output (see BURST and STACKER 
parameters) (VS2.03.810) 

character arrangement tables (see CHARS parameter) 
(VS2.03.810) 

copy modification module (see MODIFY parameter) 
(VS2.03.810) 

forms control 68,91.0 (VS2.03.810) 

modifying a data set (see MODIFY parameter) 
(VS2.03.810) 

output for (JES2) (seQ OUTPUT statement) (VS2.03.803) 
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output for (JES3) (see FORMAT PR statement) stacking the paper output (see BURST and STACKER 

(VS2.03.810) parameters) (VS2.03.810) 

printing a dump with more data per page 193.1,225 3850 Mass Storage System 

{VS2.03.810) (see MSVGP parameter on DD statement) 

printing multiple copies 66.L90 (VS2.03,810) 

printing with forms overlay (see FLASH parameter) 
(VS2.03.810) 



342.2 0S/VS2 JCL (VS2.03.803) 




Supervisor Performance*2 
Newsletter 



VS2.03.807 



This Newsletter No. GN28-2702 

Date May 28, 1976 

Base Publication No. GC28-0692-2 

File No. S370-36 

Previous Newsletters None 



OS/VS2 JCL 



© IBM Corp. 1974, 1975, 1976 



This Supervisor Performance *2 Newsletter provides replacement pages for the subject 
publication. These replacement pages remain in effect unless specifically altered. 

Supervisor Performance *2 has a prerequisite: Supervisor Performance *1 . Therefore, 
do not replace the indicated pages in the subject publication unless you previously 
installed Supervisor Performance *1 . 

Only replace Table of Contents; list of Figures, Illustrations, and Tables; and Index 
pages in the subject publication with pages from a Newsletter with a later date. 
(Newsletters with the same date contain equivalent information.) 



Pages to be replaced/ removed/inserted are: 

57, 58 (includes 58.1, 58.2) 

77, 78 (includes 77.0, 77.1) 
161, 162 
251, 252 
327 - 342 (includes 342. 1 , 342.2) 

A change to the text or to an illustration is indicated by a vertical line to the left of 
the change. 

Summary of Amendments 

The following changes have been made to this publication : 

• The default for the DPRTY parameter on the EXEC statement is modified. 

• The SETDMN and PAGEADD commands are added to the list of JCL 
operator commands. 

For a complete list of publications that support Supervisor Performance *2, see 0S/VS2 
MVS Supervisor Performance *2 System Information, GC28-0727. 



Note: Please file this cover letter at the back of the manual to provide a 
record of changes. 

IBM Corporation, Publications Development, Department D58, Building 706-2, 
PO Box 390, Poughkeepsie, New York 12602 
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Scheduler Improvements 
Newsletter 



VS2.03.804 



This Newsletter No. GN28-2703 

Date May 28, 1976 

Base Publication No. GC28-0692-2 

File No. S370-36 



Previous Newsletters None 



0S/VS2 JCL 



©IBM Corp. 1974,1975,1976 



This Scheduler Improvements Newsletter provides replacement pages for the subject 
publication. These replacement pages remain in effect unless specifically altered. 



Do not replace the indicated pages in the subject publication unless you have installed 
Scheduler Improvements. 

Only replace Table of Contents; list of Figures, Illustrations, and Tables; and Index 
pages in the subject publication with pages from a Newsletter with a later date. 
(Newsletters with the same date contain equivalent information.) 



Pages to be replaced/removed/inserted are: 

3 - 16 (includes 4.1, 4.2) 153, 154 

135 , 136 247, 248 

139 , 140 (includes 139.0, 139.1) 317, 318 

142.1, 142.2 327-342 



(includes 342.1, 342.2) 



A change to the text or to an illustration is indicated by a vertical line to the left of 
the change. 



In this publication, any reference made to an IBM program product is not intended to 
state or imply that only IBM's program product may be used; any functionally 
equivalent program may be used instead. This publication has references to the 
following IBM program product: 

RACF — Resource Access Control Facility Program 
Product 5740-XXH 



IBM Corporation, Publications Development, Department D58, Building 706-2, 
PO Box 390, Poughkeepsie, New York 12602 



©IBM Corp. 1976 



Primed in U.S.A. 



Summary of Amendments 



The following changes have been made to this publication : 

The RETAIN sub-parameter is added to the VOLUME parameter for improved 
tape handling. 

The GROUP, PASSWORD, and USER parameters are added to the JOB 
statement for RACF-defmed users. 



For a complete list of pubUcations that support Scheduler Improvements, see 0S/VS2 
MVS Scheduler Improvements System Information, GC28-0723. 



Note: Please file this cover letter at the back of the manual to provide a 
record of changes. 




IBM 3800 Printing Subsystem .^is Newsletter no. gn28-27u 

Newsletter ^^^^ May 28, 1976 

^^^■°^-^^° Base Publication No. GC28-0692-2 

File No. S370-36 

Previous Newsletters None 
0S/VS2 JCL 

© IBM Corp. 1974, 1975, 1976 



This IBM 3800 Printing Subsystem Newsletter provides replacement pages for the subject 
pubUcation. These replacement pages remain in effect unless specifically altered. 



Only replace Table of Contents; list of Figures, Illustrations, and Tables; and Index 
pages in the subject publication with pages from a Newsletter with a later date. 
(Newsletters with the same date contain equivalent information.) 

IBM 3800 Printing Subsystem has a prerequisite: Supervisor Performance *1. Therefore, 
do not replace the indicated pages in the subject pubUcation unless you previously 
installed Supervisor Performance *1. 

Pages to be replaced/ removed/inserted are; 

3-16 (includes 4.1, 4.2) 

63, 64 (includes 63.0, 63.1) 

66.1 - 68.2 (includes 66.2, 68.1) 

87- 92 (includes 87.0, 87.1,90.1,90.2,91.0,91.1,92.1,92.2) 
175, 176 
185, 186 

193 - 196 (includes 193.0, 193.1 , 195.0, 195.1) 
205, 206 

225, 226 (includes 225.0, 225.1,226.1,226.2) 
231, 232 (includes 231.0,231.1) 

287 - 290 (includes 287.0, 287.1, 288.1, 288.2, 289.0, 289.1) 
307, 308 (includes 308.1, 308.2) 
313, 314 
317 - 342 (includes 317.0, 317.1, 342.1, 342.2) 



A change to the text or to an illustration is indicated by a vertical line to the left of 
the change. 



IBM Corporation, Publications Development, Department D58, Building 706-2, 
PO Box 390, Poughkeepsie, New York 12602 



©IBM Corp. 1976 



Summary of Amendments 

The following changes have been made to this publication (to support the IBM 3800 
Printing Subsystem): 

• The addition of the BURST, CHARS, FLASH, and MODIFY parameters 
on the DD statement. 

• The COPIES and DCB parameters on the DD statement have been 
modified. 

• Additional parameters on the JESS FORMAT PR statement. 



For a complete Hst of publications that support IBM 3800 Printing Subsystem, see 
0S/VS2 MVS IBM 3800 Printing Subsystem System Information, GC26-3860. 

Note: Please file this cover letter at the back of the manual to provide a 
record of changes. 
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JES2 Release 4.0 Newsletter This Newsletter no GN28-2648 

VS2.03.803 Date May 28, 1976 

Base Publication No. GC28-0692-2 

File No. S370-36 

Previous Newsletters None 
0S/VS2 JCL 

©IBM Corp. 1974,1975,1976 



This JES2 Release 4.0 Newsletter provides replacement pages for the subject 
publication. These replacement pages remain in effect unless specifically 
altered. 

Do not replace the indicated pages in the subject publication unless you have installed 
JES2 Release 4.0. 

Pages supplied with this newsletter replace pages in the publication if no previous 
newsletter in the series VS2.03.8nn has replaced pages affected by this newsletter. 
If a newsletter page from the series VS2.03.8nn (see upper part of the page) has 
replaced a page in the publication, do not remove the page but add the corresponding 
page from this newsletter. This will result in two pages with the same page number. 

Only replace Table of Contents; list of Figures, Illustrations, and Tables; and Index 
pages in the subject publication with pages from a Newsletter with a later date. 
(Newsletters with the same date contain equivalent information.) 

Pages to be replaced/removed/inserted are: 



3- 


• 16 


(includes 4.1, 4.2) 


57- 


• 60 




65, 


66 




135, 


136 


(includes 136.1, 136.2) 


143, 


144 


(includes 144.1,144.2) 


153, 


154 


(includes 153.0, 153.1) 


211, 


212 


(includes 212.1, 212.2) 


263- 


•274 


(includes 265.0, 265.1, 268.1, 268.2 
273.0,273.1) 


317, 


318 




327 


-342 





A change to the text or to an illustration is indicated by a vertical line to the left of 
the change. 



IBM Corporation, Publications Development, Department D58, Building 706-2, 
PO Box 390, Poughkeepsie, New York 12602 
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Summary of Amendments 



The following changes have been made to this publication: 

• Additional parameters to the OUTPUT statement in 
support of the IBM 3800 Printing Subsystem. 

• Additional subparameters of the DEST parameter on 
the DD statement. 

• JES2 parameters to be used with the Accounting 
Information parameter on the JOB statement. 

• Addition of the JES2 PRTY parameter on the JOB 
statement. 

• Addition oftheJES2SIGNOFF and SIGNON 
control statements. 



For a complete list of publications that support JES2 Release 4.0, see 
0S/VS2 MVS JES2 4.0, System Information. GC23-0004. 



Note: Please file this cover letter at the back of the manual to provide a 
record of changes. 
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IBM 3800 Printing Subsystem 
12 Lines Per Inch Newsletter 



VS2.03.848 



This Newsletter No. GN28-2773 

Date September 30, 1976 

Base Publication No. GC28-0692-2 
File No. S370-36 

Previous Newsletters GN28-27 11 



0S/VS2 JCL 

© IBM Corp. 1975, 1976 

This IBM 3800 Printing Subsystem 12 Lines Per Inch Newsletter amends the subject 
publication as follows: 

IBM 3800 Printing Subsystem 12 Lines Per Inch has two prerequisites: Supervisor 
Performance 1 and IBM 3800 Printing Subsystem. Therefore, do not insert the 
attached pages unless you install the three SUs and have previously incorporated 
IBM 3800 Printing Subsystem Newsletter (GN28-271 1) into the subject publication. 



Pages To 
Be Removed 

317-317.0 



Attached Pages 
To Be Inserted 

317-317.0 



A change to the text or to an illustration is indicated by a vertical line to the left 
of the change. 

Summary of Amendments 

The list of character arrangement tables supplied with the 3800 Printing Subsystem 
is modified in this puWication. 

For a complete list of publications that support IBM 3800 Printing Subsystem 12 
Lines Per Inch, see 0S/VS2 MVS IBM 3800 Printing Subsystem 12 Lines Per Inch 
System Information, GC26-3879. 

Note: Please file this cover letter at the back of the publication to provide a record 
of changes. 



IBM Corporation, Publications Development, Department D58, Building 706-2, 
PO Box 390, Poughkeepsie, New York 12602 

©IBM Corp. 1976 
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